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1 Overview 


This document summarizes activities defining and executing the first demonstration of the 
NASA-FAA Research Transition Team (RTT) Data Exchange and Information Architecture 
(DEIA) working group (DWG). The demonstration focused on testing the interactions between 
two key components in the future Unmanned Aircraft Systems (UAS) Traffic Management 
(UTM) System through a collaborative and distributed simulation of representative scenarios. 
The summary incorporates written feedback from each of the participants in the demonstration. 
In addition to reporting the activities, this report also provides some insight into future steps of 
this working group. 


2 Background 


The NASA-FAA RTT on UTM has been in force since 2014, however recently the team has 
formalized its approaches and organization. As part of this formalization, a meeting of FAA, 
NASA and industry partners with an interest in UTM was hosted by NASA on the 21st of July 
2016. The agenda included the following: 


FAA's work to date on UAS integration activities 
The form of the RTT in terms of the working groups 
An initial UTM architecture 

Kickstarting collaboration between all stakeholders 


The development and field-testing efforts of NASA to that point had been significant enough to 
offer a platform for this working group to begin collaborative testing activities. The hope was 
that these testing activities could serve as a catalyst for other discussions within and between 
the various UTM working groups. NASA and industry tentatively agreed on a plan to architect 
and test an initial data exchange system to support UTM by the end of the 2016 calendar year. 
The result from that decision forward is documented herein. 


Additional background on the architecture under test is provided in Appendix A, but the high- 
level architecture diagram used to guide this effort is provided here for reference (Figure 1). 
Note that Figure 1 represents an updated, evolved version of the architecture in Appendix A, but 
is indicative of the same concept. While there are many components of this system, the two 
central pieces to enabling the UTM System are the Flight Information Management System 
(FIMS) and the UAS Service Supplier (USS), which are provided by the Air Navigation Service 
Provider (ANSP) and industry, respectively. This specific demonstration focused on the data 
exchanges between the FIMS and the USS; all other components and data exchanges were 
explicitly out of scope. Other exchanges needed to enable an effective demonstration were 
appropriately emulated and not necessarily documented in detail here. The philosophy with this 
initial test was to build confidence in and acceptance of the central components, thus enabling 
further definition of the other components and interfaces of the overall UTM System. 
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Figure 1: UTM Architecture 


Note that all of the NASA-related UTM discussions, implementations, artifacts, and other 
elements must be viewed as part of a research effort and not a rule-making or regulatory effort. 
The use cases discussed, the specific technologies tested, and the methods used do not 
necessarily constitute a view of how a future UTM System will look or operate. Rather, these 
exercises are used to provide insight into how such a system should or might operate. At the 
most aggressive, these activities may be seen as a validation of particular options for a future 
system, not necessarily a roadmap to a future system. 


NASA has run several other field tests and simulations leading up to the DWG demonstration 
described in this document. For further information on those tests and other related 
documentation, please see https://utm.arc.nasa.gov/documents.shtml. 


3 Related Documents 


Additional detailed information is provided in four related documents, for convenience included 
as appendices below. Appendix A is the overall plan initially formulated through discussions 
with the working group. Appendix B is the detailed implementation of the plan carried out 
through coordination with the demonstration participants. Appendix C is a technical document 
describing the interface to the NASA UTM server used by developers participating in the 
collaborative demonstration. Finally, Appendix D is the technical checkout document NASA used 
to collaboratively test that the various partner-developed systems implemented the 
specifications in Appendix C correctly. 


4 Demonstration Objectives 
For this initial demonstration of the DWG there were four high-level objectives: 


Map existing schema to requirements 
Demonstrate reasonable situational awareness 
Accelerate related efforts 

Develop an initial architecture 


Each of these objectives is described in the following subsections. 


4.1 Mapping existing schema to requirements 


NASA has been developing the concept of UTM since originating it in 2013. As such, there 
were already field-tested data schemas to support small UAS (SUAS) — UAS less than 55 Ibs. — 
research operations at low altitudes. In parallel, the FAA developed initial data requirements for 
a potential operational system to support Part 107 (non-hobbyist) and Part 101-E (hobbyist) 
operations in an automated environment. To accompany this effort, NASA endeavored to map 
the existing NASA UTM research platform schemas to the FAA-identified data requirements, 
while identifying any gaps in the requirements that would be needed to enable future automated 
management of operations and the airspace. This was an initial effort. The goal was not to 
finalize a schema for future tests and operational purposes, but to obtain a first cut ata 
reasonable schema that supported basic use cases. This first cut should be sufficient to act as 
a platform for future improvement and building in coverage of additional use cases. 


This mapping and initial schema-definition exercise was the primary objective of the 
demonstration. 


4.2 Demonstrate reasonable situational awareness 


One of the major functions of the data schema is to provide the basis for tools to provide 
appropriate situational awareness to human and automated UTM stakeholders. This 
demonstration did not prioritize this objective; however, with the implementation as tested, we 
were able to demonstrate how disparate systems could request, process, and display 
information, thus creating an initial level of situational awareness. 


4.3 Accelerate related efforts 


The sUAS industry is progressing rapidly. Research and development efforts need to keep 
pace in order to ensure safe, efficient, and fair access to the National Airspace System for these 
SUAS platforms. By building out an initial capability, soliciting feedback on how it performs, and 
sharing it amongst the stakeholders of this system, the goal is to define and refine the UTM 
concept. 


4.4 Develop initial architecture 

In order to perform this demonstration, an initial UTM architecture was required. This 
architecture, while not intended to be an operational system, can inform how a future 
operational system should be built. More specifically, through this exercise, it is hoped that 
lessons learned may help define requirements of the future operational version of UTM. 


5 Demonstration Overview 


A detailed description of the demonstration is provided in Appendices A and B. This section 
provides a short summary of the information provided there. 


The DWG developed future sUAS scenarios that would necessitate operational information 
exchanges. These included an sUAS fly-away in a remote area, incursion into a no-fly zone, an 
all-land scenario, and a capacity-management scenario. Using these scenarios together with an 
initial set of data elements that the FAA drafted for future automated waivers of Part 107 rules, 
the DWG looked for gaps in the data-exchange elements that might need to be filled in order to 
provide appropriate situational awareness for all stakeholders. By leveraging previous work by 
NASA on the UTM project, a complete data schema was drafted that is hypothesized to cover 
the situational awareness needs of the identified scenarios. 


Using the scenarios, the drafted data schema, and previous UTM architectural efforts by NASA, 
a collaborative demonstration was planned to test the data exchanges and initial architecture. 
NASA served as the ANSP within the demonstration by implementing the FIMS. Partners and 
NASA then each implemented a USS adhering to a collaboratively defined Interface Control 
Document (ICD) and Application Programming Interface (API). 


The execution plan involved having the external partners complete a software checkout to 
ensure their systems implemented the agreed-upon specification correctly, then meeting 
virtually as a group to run through several nominal scenarios, then meeting once more to run 
through the more involved scenarios. Following these steps, NASA collected qualitative 
feedback in the form of written evaluations from the partners and then produced this document. 


The testing was built up in a hierarchical fashion. First, specific Data Exchanges were identified 
(see Appendix B) based on the previously defined use cases. A single Data Exchange is a 
collection of data elements representing all of the information sent from one party to another 
party in a single data message. These Data Exchanges were then organized into sequences of 
exchanges that described an interaction between various stakeholders. These were called 
"Tests" for this demonstration. Finally, collections of these Tests were grouped to run together 
into Experiments wherein every participant had a distinct role within exactly one Test. Thus, 
individual Data Exchanges were logically sequenced into Tests which were then grouped into 
Experiments to tell the story of a particular scenario. Each experiment could be run multiple 
times with varying assignments of roles for each run. These were termed "Configurations" for 
this demonstration. 


6 Execution 


There were two dates of execution. On the 4th of November, 2016, the DWG met via a shared 
video conference and completed two Experiments. On the 14th of November, 2016, the group 
met again and completed the remaining Experiments. Overall, the execution was smooth. The 
team was able to adjust the schedule on the fly to accelerate execution, which helped end each 
day's work early. There was no absenteeism and no significant technical problems. The 
sessions were recorded and are available from NASA for appropriate use. 


7 Results 


This was not an overly quantitative demonstration. It could be better described as an 
acceptance activity or initial validation of the concept. As such, the success criteria as 
encapsulated in the demonstration objectives can be said to have been met. Each of the 
objectives are reviewed here in light of the completed demonstration. 


7.1 Mapping existing schema to requirements 


This was identified as a primary objective and can be evaluated as complete or successful 
through inspection of the resulting API. Given that the API (and associated data schema) 
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allowed for completion of the identified experiments to the participants’ satisfaction, we can 
claim there is a reasonable data mapping to meet the requirements as currently understood. 


7.2 Demonstrate reasonable situational awareness 


The NASA systems were able to see the plans and data as they were submitted. At least two of 
the UTM partners developed systems that allowed for visualization of other operators’ submitted 
data by querying the FIMS and/or subscribing to data message queues. The data they received 
were deemed reasonable for those operators to appropriately plan their operations such that 
they would avoid other conflicting operations. Thus, reasonable situational awareness was 
possible via this initial architecture. 


7.3 Accelerate related efforts 


The efforts of the DWG provided topics for discussion within NASA and within the related 
Concepts Working Group of the RTT. The format of the DWG also allowed for an initial blueprint 
for the Communication & Navigation and Sense & Avoid working groups. Thus, the efforts of the 
DWG with this demonstration aided in the acceleration of related efforts. 


7.4 Develop an initial architecture. 


This was indeed completed to allow for the demonstration to occur. From this initial architecture 
and the various lessons learned, future iterations of the architecture will be developed. 


8 Lessons Learned 


After the demonstration was complete, a qualitative report was requested from each of the non- 
NASA participants discussing their impressions of the activity. In this section, we provide some 
of this feedback — the five participants will remain anonymous and have been randomly labeled 
as Participant A through E. 


8.1 Overall Impressions 


Overall, the feedback was positive. The way in which the concept was presented and 
demonstrated resonated well with the participants. The "demonstration was successful and 
beneficial"* and the "architecture has proven to be a great starting-point."®> There was a general 
belief "that simulation is the most appropriate methodology for these kind of tests and research 
activities." "The execution of the tests was fairly smooth"? with the "demo documentation 
[being] thorough and help[ing] ... development go smoothly."= The process made "users/teams 
think about certain aspects of flight ... that would otherwise be overlooked."° Also, "the group as 
a whole learned more about this subject than it would have with each team doing these tests 
individually."® 


8.2 Architecture Design 


Several participants had detailed comments on the overall architecture of the FIMS-USS 
subsystem within UTM. Those comments are grouped by participant below. The takeaway 
message from NASA's perspective is that the individual technologies selected for this initial 
demonstration (based on prior NASA development efforts) were both reasonable, at least for the 
demonstration, and also potentially applicable for future implementations as an operational 
system. As noted by several participants—and as known by the NASA UTM project—the 
technologies were not tested or selected based on a full engineering analysis. Such an analysis 
is needed in the future and should include elements of cybersecurity, scalability, reliability, and 
other measurable qualities. 


8.2.1 Comments of Participant "B" 


"It allows an authority (such as the FAA) to both audit ongoing sUAS flight operations, as well as 
intervene with specific restrictions when necessary. Especially notable is the fact that it is 
designed on the concept of 'no human in the loop' of operations—meaning that it can ultimately 
scale to meet demand. This exercise was limited enough in scope that the working group could 
demonstrate the basic functionality of the architecture—although there are still plenty of hurdles 
before we can confirm that this works in all cases. 


"The NASA-designed scheme supports provisions for many features that are not yet supported 
in the implementation. Of course, much of this design will require some degree of refactoring as 
the implementation evolves and is tested, but the NASA designed architecture suggests how 
these features could be incorporated into a more comprehensive and scalable implementation. 


"The current design relies on a mix of technologies, with HTTPS at the core and higher-level 
components (i.e. “web sockets”) on top of this. This makes the implementation of a UTM client 
somewhat clumsy. It would be relatively straight-forward to develop a simpler approach that 
would streamline this implementation and eliminate the dependency on higher-level constructs. 


"No attention was given to concepts such as: (a) detecting/preventing loss of data, (b) the 
system’s methods and processes for identifying/reacting to delayed data transmissions or 
vehicles that lose communication. Although these were not an objective of the initial trial, we are 
confident that these issues can be addressed in future trials." 


8.2.2. Comments of Participant "'C" 


"We are in support of using RESTful APIs and use of STOMP was a good choice. Down the 
line, we may as a group need to look at the scalability/load testing aspects of the solution when 
UTM goes past the limited research/experimentation traffic." 


8.2.3 Comments of Participant "D" 


"[It was] beneficial to test stomp as a data exchange mechanism [but as a] sender [it was] hard 

to maintain connections. [We] lost messages if not connected until [we] went to full broker [and 

it] worked better in TCL2. Swagger was great for specifics about APIs [but] no change history to 
clearly point out changes." 


8.2.4 Comments of Participant "E" 


"The REST/STOMPoverWS combination is not the most natural to code against. It might be 
more performant at scale to have positions sent via WS as well. STOMP was actually very easy 
to work with and is an easy protocol to debug because it is text based." 


8.3. Development Process 


The planning and execution of the demonstration occurred between July and November 2016. 
This timeline was extremely tight. The aggressive schedule was driven by many factors, 
including other UAS/UTM related activities on the calendar, providing input to the other working 
groups, keeping momentum on the overall effort moving forward, amongst others. The activity 
was impacted by other parallel UTM project efforts, not the least of which was the TCL 2 
Demonstration held at Reno-Stead airport in Nevada in October 2016. That demonstration was 
the highest priority for the UTM project given the long lead times for performing live, beyond 
visual line of sight (BVLOS) flights in the National Airspace System in coordination with dozens 
of partners. Thus, the NASA software development team was splitting time between competing 
versions of the server side of UTM, with the TCL 2 Demonstration taking priority. Also, it needs 
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to be noted that the concepts driving this DWG demonstration were being developed in parallel 
with the software. 


All of these issues negatively affected the partners participating in this DWG demonstration. The 
documentation from NASA that was required for the partners to build their software clients was 
often incomplete and/or late arriving, necessitating many last-minute adjustments to their code 
and our collaborative plans. Below are some quotations from the partners related to this impact: 


e "The only gripe we have is that the interfaces/AP|/Parameters were changing [until] the last 
minute (some not even in line with the documentation) for each of the two tests which 
required last minute troubleshooting and changes."° 

e "FIMS was operated in a manual way which made it difficult to develop against when it only 
worked with operators on the back end."" 

e "Many API changes right up to the client checkout requiring us to essentially certify twice."° 

e "Too many API and messaging changes close to the end that required significant effort... 
Breaking changes so we had to code on the spot."? 

e "Only very near the test did the FIMS start posting geometries for closures."° 

e "Without participant access to Confluence, we were always working with old 
documentation."° 

e "In the future, it might be better to be more specific about flight paths and UAV speeds to 
reduce the amount of waiting."= 

e "Testing should be made simpler as the implementation evolves. Many of the test cases in 
this trial required manual intervention to inject simulated events. It is preferable to automate 
these events so that the client tests could be easily regression-tested as well as expanded 
in scope."® 

e "Operation areas did not always line up with the defined scenario. Some of the operating 
areas that were supposed to be in compliance were submitted in no-fly areas. Some of the 
submitted geometries seemed to have points that were not in order or transposed."4 


8.4 Summary 


Synthesizing the feedback, the following may be a reasonable list of lessons learned to help 
guide future demonstrations: 


e Provide adequate time for planning and implementation of future demonstrations. This 
includes appropriate planning in conjunction with all of the UAS/UTM activities to ensure 
availability of resources to appropriately execute. 

e Build on the architecture and open up the technology choices to include more future 
operational requirements. 

e Define parameters even more precisely for simulated operations to ensure smooth 
compatibility. 

e Attempt to open up the documentation process to avoid outdated, slow releases of required 
information. 


9 Next Steps 


This demonstration helped highlight and test a reasonable architecture for the future UTM 
System, including definitions of several key data exchanges. However, this demonstration 
focused on communications between the ANSP and users of the airspace. In architectural 
terms, the only data exchanges exercised were those between the FIMS and USS. Moving 
forward, there are several other data exchanges that need to be formalized. Of current highest 
priority are the exchanges between various USSs (i.e., USS-to-USS communication). Some of 
the basic questions are as follows: 


1. What data are required to be shared amongst USSs? 

2. How should those data be shared? 

3. How does a USS become vetted? 

4. How do other stakeholders "find" or "discover" a USS? 

There are many other questions that can be formed. Via the DWG, NASA will define these 
questions and develop additional collaborative demonstrations to prove and refine the concepts. 
In addition to USS-to-USS communication, the other high-value technical questions to be 
addressed include, but are not limited to the following: 


1. How is authentication, authorization, and accounting achieved within the UTM System? 
2. How do public safety and other public entities interact with UTM? 

3. What is the general discovery mechanism needed for the various components in UTM? 
4. What levels of quality of service are required for the various components in UTM? 

5. What, precisely, is the complete set of roles and responsibilities in UTM? 


Each of these questions, as well as others not explicitly listed, need discussion, documentation, 
and some level of testing. These will be the issues dictating the next steps of the DWG. 


10 Conclusion 


NASA previously conducted simulations and flight tests as part of the UTM Project, but the effort 
described here was the first under the banner of the NASA-FAA RTT for UTM. Not only was the 
demonstration successful, it provided a solid foundation for future demonstrations, helped give 
some clarity to the overall concept development, offered a chance for more industry partners to 
have direct input on the concept, and produced lessons-learned that can make future 
demonstrations even more successful. The DWG is an excellent resource for the RTT and the 
UTM cause as a whole. Leveraging this resource by actively engaging in demonstrations and 
producing software artifacts will help push the concept along. 


11 Appendix A —- DWG Demonstration 1 Plan 


The content of this appendix was originally a stand-alone document. The information contained 
herein represents the initial planning of the demonstration and may be out of sync with the 
actual execution as described in the main document or the more recently written Appendix B. 
This appendix is included for completeness, reference, and context. 


11.1 Overview 


This document describes the plan for a collaborative demonstration between NASA and industry 
partners as part of the UTM RTT Data Exchange Working Group (UTM-DWG). This 
demonstration will exercise the initially proposed data exchange models for the UTM System. 
The focus of the initial models and this demonstration is upon the data exchanged between the 
operator and the Airspace Navigation Service Provider (ANSP). To demonstrate the data 
exchange, the initial models will be developed to support specific demonstration scenarios. 
Those scenarios are described in this document. Given that the scope of this collaborative 
demonstration is limited to the exchange between operator and ANSP, there may be future work 
and demonstrations for other aspects of the overall data exchange model in the UTM System. 


11.2 Background 


On Wednesday, July 20th, 2016 NASA hosted a meeting that included representatives from the 
FAA and several partners from industry and academia interested in SUAS access to the low- 
altitude airspace. This meeting represents an element of the overall NASA-FAA Research 
Transition Team effort related to UTM research. The FAA provided some background on their 
UAS work to date and their current thoughts on how sUAS may access the airspace in the 
future. The FAA is seeking input to inform this process and proposed five working groups. The 
first of these to begin is the UTM-DWG. A self-selected subset of those organizations in 
attendance met the following week on Wednesday, July 27th, 2016. NASA produced this 
document as a result of that initial meeting. 


At the July 20th meeting, the group used a diagram supplied by NASA as a basis for discussion 
of the overall concept and the flow of data in particular. That diagram has evolved into the 
following: 


UTM Architecture 
version 2016.12.05 


NAS Data Sources 


| National 
Airspace System 
| 


Color Key: 


Figure A-1: UTM Architecture 


This diagram should not be considered final. Discussions are ongoing and will be informed by 
this collaborative demonstration. 


11.3 Current Scope 


The scope of this working group is driven by test scenarios for this collaborative demonstration. 
Those test scenarios are detailed below. To focus the technical discussion on a manageable 
and meaningful part of the diagrams above, the connection between the USS and the FIMS will 
drive the technical work associated with this demonstration. This does not intend to lessen the 
importance of the other connections in the diagram and eventual UTM System, however, 
through the process of defining and developing the FIMS-USS connections, the requirements 
and path forward for the other connections may become clearer. 


11.4 Deliverables 


This activity will produce, at a minimum, the following deliverables (Table A-1). The customer 
for these deliverables is UTM Research Transition Team including NASA, FAA, other 
government participants, and industry partners. 


Table A-1: Deliverable DWG Artifacts 


Date Artifact(s) Description 

TBD Demonstration plan document A final version of this document. 

TBD Data collected during e Log of communications to and from FIMS 
demonstration e Log of communications to and from each Operator 
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Date Artifact(s) Description 
e Any media recorded during demonstration (telecon, videocon, 


etc.) 
TBD Qualitative statements Each participant will provide feedback on the working group and 
demonstration. 
TBD Plan for future UTM DWG retiring? continuing with additional demos? etc. 


11.5 Test Scenarios 


11.5.1 Assumptions 


The scenarios are detailed in the following subsections. For each scenario, the following 
assumptions are in place: 


e Operations are BVLOS of the UAS controller. 

e BVLOS operations require notification of intent. 

e The Operator acts as a "full stack" operator (UAS, UAS Operator, USS, Supplemental Data 
Service Provider all under control of one entity) 

e These are not real flights, only simulated. 

e Any roles that are believed to be filled by humans will be filled by humans for the 
demonstration/test. 


Note that not all of these assumptions are necessarily part of any future operational 
environment. These assumptions simply provide a clearer baseline for all participants in the 
demonstration. 


11.5.2 Scenario 1: Operator Incursion 


11.5.2.1 Overview 


While performing an operation near the boundary of U.S. National Park that is located in a 
suburban or urban area, an operator inadvertently crosses over that boundary. This incursion 
into an unauthorized area will trigger a series of data exchanges between the operator and the 
FIMS, these exchanges may trigger further data exchanges between: 


e FIMS and other operators 
e The offending operator and other operators 
e FIMS and other NAS elements 


This scenario will exercise data exchanges that occur for operations flying near and within 
National Park boundaries. 


11.5.2.2 Story A 


An operator plans an operation in a populated area. This operation's planned trajectory keeps it 
clear of all known constraints. The platform being flown has been registered with the ANSP for 
operation in the airspace and meets all operational and maintenance requirements. The 
operator has the appropriate licensing and credentials to perform such operations. The 
operator begins the operation as planned, however during the operation the vehicle deviates 
from its planned course and enters airspace that is restricted to SUAS operations. This 
incursion is into a national park area. As soon as the operator is aware of the incursion, it sends 
a message to the FIMS indicating a deviation in its intended operation. This communication 
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occurs in parallel with the operator's attempts to correct the incursion. The operator receives 
directives from the FIMS to correct its current trajectory. Other nearby operators receive 
directives and messages related to the offending operation. The operator is able to correct the 
trajectory and return its operation to the originally intended plan. The operator updates the 
FIMS on its deviation status. Figure A-2 shows an example sequence diagram for this scenario. 


interaction UTM DWG: Unintended entry to no-fly zone 
Operator Flight Information 
Management System 
' Begin operation 


' Incursion into no_fly zone 


' 
par Operator actions post incursion 
‘ 
H 


: ' 
‘ Notify of incursion > 
H H 
‘ Incursion notice received 


' H 
‘ H 
fererererss ce pee ee ee gare a: % 
H Deviation request received 4 


‘ Correct trajectory 


Figure A-2: Incursion into No-Fly Zone 


11.5.2.3 Story B 


An operator plans an operation in a populated area. This operation's planned trajectory keeps it 
clear of all known constraints. The platform being flown has been registered with the ANSP for 
operation in the airspace and meets all operational and maintenance requirements. The 
operator has the appropriate licensing and credentials to perform such operations. The 
operator does not have any special role or credentials (e.g. public safety). The operator begins 
the operation as planned, however during the operation the operator notices an opportunity for a 
more optimal flight plan that would take the UAS over National Park territory. The operator 
sends a request to the FIMS for access to the nominally off-limits area for a time-limited, 
planned incursion. The FIMS receives the request and approves it. The operator adjusts the 
flight plans accordingly and completes the operation including the segment through the National 
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Park territory. When trying the same request for a similar operation at a later time, the request 
is not granted and the operator is obliged to use the original plan for that second operation. 
Figure A-3 shows an example sequence diagram for this scenario. 


interaction UTM DWG: Request to enter no-fly zone 


Operator Flight Information 
Management System 
' Plan operation 


Notify of operation 


KRennnneneeeeeeeceneeeeeeeeecceeeeseseeeesoostSeeerta 


' Process request” 


Request received 


Decision regarding request 


alt FIMS decision ) : 


[APPROVED] 


ee 
' Hl 


[REJECTED] 


Figure A-3: Request to Enter No-Fly Zone 


11.5.2.4 Story C 


An operator plans an operation in a populated area. This operation's planned trajectory keeps it 
clear of all known constraints. The platform being flown has been registered with the ANSP for 
operation in the airspace and meets all operational and maintenance requirements. The 
operator has the appropriate licensing and credentials to perform such operations. The 
operator does not have any special role or credentials (e.g. public safety). The operator begins 
the operation as planned. During the flight, the vehicle deviates from its planned trajectory, 
though does not enter any "no-fly" areas. The operator begins to take corrective actions while 
announcing the deviation to other stakeholders. 


11.5.2.5 Discussion 


To focus this scenario, two specific National Parks will be used. More precisely, two National 
Historic Sites will be used. The first is the John Muir National Historic Site in Martinez, CA, 
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which is in the Bay Area to the east of San Francisco, CA. The second is the William Howard 
Taft National Historic Site located in Cincinnati, OH. GeoJSON descriptions of these areas are 
provided here: 


https://gist.github.com/alotau/4ff38d0 1 fa6a7dee6132e474c3bf08bf 


These data were collected from the US Department of Transportation data website. 
Specifically, the URL for the National Park data is: 


http://www. rita.dot. gov/bts/sites/rita.dot. gov.bts/files/AdditionalAttachmentFiles/parks.zip 


The shapefile within that zip file was imported to QGIS. The specific sites were extracted using 
QGIS and exported as a GeoJSON file. 


The focus of this scenario is on the exchange between the operator and the FIMS. As a stretch 
goal, other exchanges may be investigated. The technical mechanisms for data exchange will 
not be finalized with this demonstration, however, various options may be discussed and a 
reasonable method for actually sending and receiving data will be chosen by the working group. 
This chosen method may inform future demonstrations and working groups. 


The working group will decide on the necessary and sufficient data to be exchanged to satisfy 
this scenario from all involved perspectives (ANSP and operator). 


11.5.2.6 Questions 


What are the time requirements for these communications? How quickly must operator report? 
How long can the operation fly in the constraint before some other action by ANSP takes place? 
Which other operators should be notified? What directives, if any, are they provided? 

What if there is surveillance active in these areas? Do those systems alert anyone? 


11.5.3 Scenario 2: Airspace Constraint Change 


11.5.3.1 Overview 


Operations are allowed near an airport, but the available areas are dictated on the current 
runway configuration. An unplanned configuration change triggers data exchange between the 
FIMS and operators. While the initial data exchange is a push from the FIMS, subsequent data 
exchanges would be required to keep operations in the appropriate areas. 


11.5.3.2 Story 


Mineta San Jose International Airport (SUC) has parallel runways 12L-30R/12R-30L and has 
two major flows: South Flow and North Flow indicating the direction of the departing and 
arriving traffic. These configurations typically change based on weather (wind) events. Given 
the altitude of the manned aircraft on approach, the arriving traffic has a protected zone added 
to keep sUAS from operating in that zone. Thus, on a configuration change, that zone changes 
as well. When a configuration change happens, there is a ten-minute delay before any arrivals, 
thus the ANSP allows for a five-minute period for existing operations to clear the newly 
established protected zone. New sUAS operations may immediately use the other protected 
zone that was deactivated. 


11.5.3.3 Discussion 

A pseudo (hand drawn) dataset for the airport configurations was hastily created and placed 
here: 
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https://gist. github.com/alotau/cfd4695f79208acOb980b00259cbac9c 


If real-world data for an airport configuration change is easily available for an airport in an urban 
area, we should substitute those real data. 


11.5.3.4 Questions 


What does the constraint announcement contain from the FIMS? 

How do operators with active operations in the new constraint react safely? 

What if they can't land within five minutes? 

Should they not have been allowed to operate in that zone in the first place in that case? 
What if they can't land within five minutes due to some safety issue? 

How does the airport ultimately get notified? 

Are the time values proposed reasonable? 


11.5.4 Scenario 3: All Land 


11.5.4.1 Overview 


This scenario exercises the case where the ANSP provides a directive to all operators to clear 
the airspace (also known as an "all land" scenario). There will be operations that are active that 
need to land and operations planned for the near future that need to stay grounded. 


11.5.4.2 Story 


A national security issue is affecting the entire conterminous United States. The ANSP decides 
it is safest to ground all SUAS operations until further analysis of the situation can be completed. 
A message from the FIMS provides the directive for all active operations to go to ground within 
the next five minutes and to cancel any planned operations. Operators submit their deviation 
plans to comply with the directive and commence grounding operations. Operations that are in 
an unsafe or unknown state are reported to the FIMS to allow the ANSP to incorporate that 
information into NAS-wide contingency management. 


11.5.4.3 Discussion 


This seems like an important functionality to begin hashing out. We need to think about how 
each type of operation might be affected by such a scenario. This can help make the 
discussion about the need for reliable communication between FIMS and USS more concrete. 
The argument should be that each operation should be reachable within some time window to 
enable these types of contingencies. 


11.5.4.4 Questions 


1. What does the directive look like? 

2. What time parameters make sense? Time to execute, time to notify of diversion plans, 
time to notify of failure to comply, etc. 

3. What do the messages from the operator look like? 

4. What happens to priority operations (public safety, military, etc.) in this scenario? 
Should we mock them out? 


11.5.5 Scenario 4: Dense Operations 


11.5.5.1 Overview 


Despite the vast airspace and current low density of SUAS operations, there are cases in the 
future where multiple SUAS will seek to access the same volume of airspace. There may be a 
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need to implement some traffic management directives to maintain safety and efficiency in the 
system. At the very least, there should be availability of data for operators to make informed 
decisions about their operations with respect to other known SUAS operations. This scenario 
aims to explore this issue in terms of the data exchanges necessary to support these operations 
and the ANSP. 


11.5.5.2 Story 


The daughter of a B-list actor is getting married. The day of the wedding sparks a plethora of 
activity at the site of the event. The videographer is planning to use two SUAS to capture aerial 
shots. Paparazzi drones want to perform a few flybys to capture footage. Some last-minute 
items are ordered by the caterer for the reception requiring three separate drone deliveries. 

One of the guests realize that their favorite beverage is not available at the bar and orders some 
to be delivered directly to him via SUAS. Meanwhile in the park next door to the site, there is a 
soccer game being recorded by a separate SUAS. In addition, there is a planned surveying 
activity by the state of the local roads. The local police also routinely patrol with drones at 
various times during the day along/above the public streets. Each operation announces its plan 
to operate per requirements since the wedding site is within 2 miles of an active airport. 


11.5.5.3 Discussion 

This is an artificial, though possible, scenario. The goal is to begin investigating what data need 
to be exchanged to keep the airspace safe and efficient. We will not focus on the algorithms or 
rules that the FIMS may use to calculate capacity of the airspace. 


An initial area where this might fictionally occur is proposed here (near San Francisco (SFO) 
and San Carlos airports, has parks, suburban/urban environment): 


https://gist. github.com/alotau/f01lad7fdf4571061819c6a7e27b85cc5 


11.5.5.4 Questions 


1. Are the operation notifications really requests in this scenario? 

2. ls there a static procedure/rule that operator should follow in terms of managing the 
density of operations? 

3. Does the FIMS keep track of the density of operations? 

4. How does the FIMS notify if a critical density is reached? 

5. How do USSs respond? 


11.6 Data 


To facilitate the scenarios described above, the data to be exchanged need definition. For this 
process, concepts from the FAA and NASA are used as a starting point to identify gaps and 
suitability for these scenarios. 


11.6.1 Initial Requirements from FAA 


The FAA has some initial thoughts on the data to be exchanged between the operator and the 
FIMS. These are detailed in the Table A-2 below: 
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UAS Operator (Part 101-E and Part 107)! Data Exchanges with FIMS 


Table A-2: Initial FAA Data-Exchange Requirements 


Flight Request (Operator -> FIMS) Flight Authorization (FIMS -> 


Operator) 
e Operator Information e Indication if flight information is e 
o Operator Name submitted too far in advance of 
o Phone Number operation 
e_ = Aircraft Information e Indication that flight information 
o Registration Number has been received 
(or Serial Number if e Response to flight operation 
<250g) request: 


e Operation Information 


(2) 


[e) 


Indication whether 
operation is under Part 
101-E, Part 107, or Part 
107 waiver; If waiver 
then: 
= Waiver 
Certificate e 
Number 
Date of Proposed 
Operation 
Start Time of Operation e 
Duration of Operation 
Geographical Operating 
Area 
Maximum Operating 
Altitude 
= Indication if 
operating within 
400ft radius of 
structure 
Purpose of Operation 
(voluntary) 


e Acceptance of Terms and 
Conditions 

e = Flight denial challenge (Part 
107 only if flight is initially 


denied) 


o Accepted (Part 101-E) 
/ Authorized (Part 107) 


o Denied 
o ATC notification not 


required (Part 101-E) / 
ATC authorization not 


required (Part 107) 
Changes in authorization 
status prior to proposed flight 
(acceptance/authorization -> 
denial) 

Changes in authorization 
status during the proposed 


flight (acceptance/authorization 


-> termination) 


Flight Status (Operator -> 
FIMS)? 


Cancellation of flight 
operation (prior to 
operation) 


Change in flight operation 
end time (if operation ends 
earlier than originally 
planned; extension requires 
new request) 

Operator acknowledgement 
that flight operation will no 
longer be conducted (if 
initially accepted / 
authorized, then denied or 
terminated by ATC) 


1 The data elements identified herein are limited to Part 101-E and Part 107 data exchanges 
with the Flight Information Management System (FIMS), and are not inclusive of all possible 
operations that require notification/authorization in lieu of an IFR flight plan. 

2 The UAS Operator will access relevant NAS information via NAS Data Services to ensure 
regulatory compliance and safety of flight. NAS Data Services may provide information such as 
locations of Special Activity Airspace, controlled airspace boundaries, airspace within 5 miles of 
an airport, airport-specific “no-fly zones” and “fly zones”, and other areas designated as “no-fly 


zones”. 
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11.6.2 Initial Implementation by NASA 


The following are a subset of the elements from NASA's current (as of this writing) 
implementation of UTM. More details are available in the UTM Client Interface Control 


Document. 


11.6.2.1 Operation 


An operation within NASA's research platform consists of vehicle, operator, and intent 
information for a particular SUAS operation — this information is listed in Table A-3 below. Note 
that this table is directly from the ICD so some context for the comments and section references 


may be missing. 


Table A-3: Vehicle, Operator and Intent Information 


Field name Data type 
gufi String, UUID 
submit_time String, Date 
decision_time String, Date 
aircraft_comments String 
flight_comments String 


flight_geography_description String 


registration String, UUID 
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Req’don Allowed on Description 
submission submission 


No. No. Each operation has a 
globally unique flight 
identifier (GUFI) assigned 
upon submission. It is a 
JSON siring that conforms 
to the UUID version 4 
specification (see Section 
3.1) 


No. No. Time the operation 
submission was received 
by UTM System. 


No. No. A timestamp set by the 
UTM System any time the 
state of the operation is 
updated, for example 
when the flight goes from 
PROPOSING to 
ACCEPTED (see Section 


4.1) 

No. Yes. Informative text about the 
aircraft. Not used by the 
UTM System. 

No. Yes. Informative text about the 


operation. Not used by 
the UTM System. 


No. Yes. Informative text about the 
operational geography. 
Not used by the UTM 
System. 


Yes. Yes. The registration ID of the 
vehicle flying this 
operation. Note the UTM 
System assumes a single 
vehicle per operation 


Field name 


flight_number 


unmanned 


user_id 


created_by 


primary_contact_name 
primary_contact_phone 
primary_contact_email 


secondary_contact_name 
secondary _contact_phone 
secondary _contact_email 


Data type 


String 


String, Boolean 


String 


String 


String 


String 


Req’don = Allowed on 
submission submission 


No. Yes. 
Yes. Yes. 
No. Yes. 
No. No. 

Yes. Yes. 
No. Yes. 


Description 


currently. This registration 
value is provided to 
operators upon manual 
registration of their vehicle 
with NASA. See Section 
4.3.3. 


Optional. Currently 
unused by the UTM 
System, may be useful to 
the operator for 
identification purposes. 


Please include 


“unmanned”:”true” with all 
submissions. 


This field is populated 
based on the provided 
credentials in the HTTPS 
header. If submitted by a 
user, the value will be 
ignored. 


The user that created the 
operation. It is possible 
that an operation is 
created on behalf of an 
operator by, say, a 
manager. Nominally, this 
field will be equal to 
user_id. 


These are required fields. 
They are not currently 
checked for validity, but 
clients should endeavor to 
provide useful, appropriate 
information in these fields. 
Validity will be checked in 
the future. These values 
should represent the 
contact that should be 
used in case of an issue 
with the operation before, 
during, or after that 
operation. 


These are optional fields. 
They are not currently 
checked for validity, but 
clients should endeavor to 
provide useful, appropriate 
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Field name 


extra_contact_info 


state 


controller_location 


gcs_location 


faa_rule 


waiver_certificate_number 
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Data type Req’don Allowed on 
submission submission 

String No. Yes. 

String No. No. 

Geometry of type Yes. Yes. 

POINT 

Geometry of type No. Yes. 

POINT 

String No. Yes. 

String No. Yes. 


Description 


information in these fields. 
Validity will be checked in 
the future. These values 
should represent the back- 
up contact that should be 
used in case of an issue 
with the operation before, 
during, or after that 
operation. 


Any additional contact 
information that may be 
useful (hours of 
availability, fax number, 
communication limitations, 
etc.). 


The current state of the 
operation. Not required 
for submission, will be 
assigned by the UTM 
System. 


The planned position of 
the VAS Controller during 
the operation. Assumed to 
be a static location. 


If not submitted, the UTM 
System will assume the 
GCS is co-located with the 
UAS Controller. Assumed 
to be a static location. 


Indication whether this 
operation is under Part 
101-E, Part 107, Part 107 
waiver, or a Part TBD. 
Part TBD is a potential 
future rule that may cover 
operations such as those 
under test by UTM. 


If a waiver has been 
obtained for the Part 107 
rules, then the operator 
would have a waiver 
certificate number. For any 
operation submissions 
with 
faa_rule=PART_107W, 
this field is required. 


Field name Data type Req’don Allowed on Description 
submission submission 


operation_volumes Array of type Yes. Yes. The actual geographical 
operation_volume information for the 
operation. 


11.6.2.2. Operation Volume 


Operation volumes are used to describe where and when an operation is to take place. Multiple 
operation volumes can be used for a single operation. This promotes more efficient use of the 
airspace by allowing operators to only claim/announce use of the airspace they really need 
during a particular time period. Table A-4 describes the information used to describe an 
operation volume. 


Table A-4: Operation Volume Information 


Field name Data type Req’d on Allowed on Description 
submission submission 


ordinal Integer Yes. Yes. This integer represents the 
ordering of the operation 
volume within the set of 
operation volumes. Need 
not be consecutive integers. 


effective_time_begin String, Yes. Yes. Earliest time the operation 
Date will use the operation 
volume. 
effective_time_end String, Yes. Yes. Latest time the operation will 
Date done with the operation 
volume. 
actual_time_end String, No. No. Time that the operational 
Date volume was freed for use by 
other operations. 
conformance_time_begin String, No. No. Assigned by UTM System. 
Date Time buffer before the 
submitted begin time. 
conformance_time_end String, No. No. Assigned by UTM System. 
Date Time buffer after the 
submitted end time. 
min_altitude_wgs84 ft Number, Yes. Yes. The minimum altitude for 
Double this operation in this 


operation volume. In 
WGS84 reference system 
using feet as units. 


max_altitude_wgs84_ft Number, Yes. Yes. The maximum altitude for 
Double this operation in this 
operation volume. In 
WGS84 reference system 
using feet as units. 
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Field name Data type Req’d on Allowed on Description 
submission submission 


conform_min_altitude_wgs84_ ft Number, No. No. The minimum altitude 
Double assigned and used by the 
UTM System to check 
vertical conformance of an 
operation. Based on UTM 
Client-provided min altitude. 


conform_max_altitude_wgs84_ft Number, No. No. The maximum altitude 
Double assigned and used by the 
UTM System to check 
vertical conformance of an 
operation. Based on UTM 
Client-provided max altitude. 


flight_geography Geometry Yes. Yes. A description of the 
operational area. This 
should be the area within 
which the operation will 
remain. 

conformance_geography Geometry No. No. A UTM-generated 
geography based on the 
flight geography. See 
Section 4.4.2 for discussion. 


11.6.2.3 Messages 


To convey information between the UTM Core and operators within the UTM research platform, 
message can be exchanged. The schema for messages is presented in Table A-5 below: 


Table A-5: Message Information 


Field name Data Required from Allowed from Description 
type Client upon Client upon 
submission? submission? 


message_id String, No No Unique identifier 
UUID 
origin String No No Must take exactly one of three values: 


e CLIENT. Message is from a UTM Client 
to the UTM System. 

e UTM: Message was automatically 
generated by the UTM System. 

e MANAGER: Message was generated by 
a UTM Manager (a human). 


user String No No Populated by the UTM System. The target 
user for a message from the UTM System. 
gufi String, Yes Yes The assigned GUFI for the operation 
UUID referenced by the message. 
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Field name Data 


type 
category String 
free_text String 
sent_time String, 

Date 
ack_time String, 

Date 


alert_message String 


alert_severity String 


intent_message Siring 


Required from Allowed from Description 


Client upon 
submission? 


Yes 


No 


No 


No 


No 


Yes 


Client upon 
submission? 


Yes 


Yes 


No 


No 


No 


No 


Yes 


The type of message. Must take exactly one 

of the following values: 

e INFORM: The UTM System sends this 
message when an operation changes 
state for any reason. 

e INTENT: A message from a UTM Client 
or UTM Manager requesting a state 
change in an operation. 

e ALERT: An alert sent from the UTM 
System or UTM Manager to UTM Clients. 

e RESPONSE: A response from the UTM 
System to a UTM Client/Manager that a 
prior message was received. 

e FREE: A free text message. 


Any free text. Not used in an automated way 
by the UTM System and is optional. 

Either the time the message was sent by the 
UTM System or the time it was received by 
the UTM System. 

Applied by the UTM System. Further 
documentation on this element not available. 
Only included with messages from the 
ALERT category. Must take one of the 
following values: 


e WEATHER 

e SECURITY 

e OPERATIONS 
e SYSTEM 


Only included with messages from the 
ALERT category. Can take the following, 
increasingly important values: 

e INFORMATIONAL 

NOTICE 

WARNING 

CRITICAL 

EMERGENCY 


Only included with messages from the 
INTENT category. Can take the following 
values referring to state changes that are 
requested by a UTM Client or UTM Manager: 
e ALL_CLEAR 

e CANCEL 

e CLOSE 
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Field name Data Required from Allowed from 
type Client upon Client upon 
submission? submission? 


inform_message Siring No No 
violations Array No No 
warnings Array No No 


Description 


Only included with messages from the 
INFORM category. Can take the following 
values referring to states of an operation: 
e ACCEPTED 

REJECTED 

ACTIVATED 

CANCELED 

CLOSED 


Included with messages from the INFORM 
category with inform_message = 
REJECTED. The array is of pairs of types 
and constraining_ids. The type refers to a 
constraint in the system (national parks, 
airports, etc.) and the constraining_ids are 
the UUIDs associated with those constraints. 
This will allow for querying of the system for 
more information about those particular 
constraints. 


An array of type, warning_id, message 
triplets. 


11.6.3 Mapping FAA Initial Requirements to NASA UTM Research Platform Schema 
In this section, we present an initial mapping of the FAA's initial thoughts on data exchange with 


the existing NASA schema (Table A-6). 


Table A-6: Initial Data Exchange Mapping 


FAA Statement 
Operator Information Operation: 
e Operator Name 
e Phone Number 


Aircraft Information Operation: 


e Registration Number (or e registration 


Serial Number if <250g) 
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NASA Data Element 


user_id 
primary_contact_name appears more (or overly) complete for 
primary_contact_phone the FAA's purposes. Note that in the 
primary_contact_email | NASA UTM research platform, each 
secondary_contact_name user_id is associated with a specific 
secondary 
_contact_phone 
e secondary 
_contact_email 


Discussion 


This is a relatively clean mapping of 
data elements. The NASA schema 


operator. Typically, the operator in the 
UTM research platform would be an 
organization. That operator may have 
several user_id's associated with it. It is 
the user_id that is submitted with the 
operation, thus allowing a look up of 
the associated operator. 


This is a relatively clean mapping. In 
the UTM research platform, each 
vehicle is required to be registered. 
That registration includes a set of 
performance characteristics that may 


FAA Statement NASA Data Element 


Operation Information - 
e Indication whether operation 
is under Part 101-E, Part 107, 
or Part 107 waiver; If waiver 
then: 
o Waiver Certificate 
Number 


Operation Information Operation: 

e Date of Proposed Operation e¢ operation_volumes 

e Start Time of Operation Operation_volume: 

e Duration of Operation e = effective_time_begin 

e Geographical Operating Area e  effective_time_end 

e Maximum Operating Altitude e min_altitude_wgs84_ft 

o Indication if operating «© max_altitude_wgs84 ft 

within 400ft radius of e — flight_geography 
structure 


Operation Information 
e Purpose of Operation 
(voluntary) 


Operation 
flight_comments 


e Acceptance of Terms and - 
Conditions 


Discussion 


be useful in contingency or capacity 
management activities. A successful 
registration of a vehicle in the UTM 
research platform provides a UUID for 
that registered vehicle, which is the 
value required in the registration field. 


Suggesting the addition of a new field 
to the operational plan. An enumerated 
string field called "faa_rule" to indicate 
which FAA rule is being used for this 
operation that is required upon 
submission with the following allowed 
values: 

e Part 101-E 

e Part 107 

e Part 107 Waiver 

Add an additional field for Waiver 
Certificate Number that is only required 
if "faa_rule" has the value "Part 107 
Waiver". This field will be a string with 
the name "waiver_certificate_number" 
and its value will be the waiver 
certificate number that was supplied by 
the FAA. 

Currently no other information from the 
FAA has been received on these 
values. 


Each operation in the UTM research 
platform provides a set of 
operation_volumes to define where 
and when it will be operating. This 
maps cleanly to the data elements 
requested by the FAA. The only gap is 
the "indication if operating within 400ft 
radius of structure.” Further details on 
this data requirement may be needed 
from the FAA side. An additional field 
may be required by the UTM research 
platform to accommodate this data 
element. 


This is a clean mapping of voluntary 
fields. The only concern is the potential 
overloading of the flight_comments 
field if it is used for other purposes in 
addition to "purpose of operation." 

An argument can be made that use of 
the system implies acceptance of 
terms and conditions of the system. 
However, if this must be explicit, a new 
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FAA Statement 
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NASA Data Element 


Flight denial challenge (Part 
107 only if flight is initially 
denied) 


Indication if flight information Message 
is submitted too far in e INFORM 
advance of operation e = INTENT 
Indication that flight 
information has been 
received 
Response to flight operation 
request: 
o Accepted (Part 101- 
E) / Authorized (Part 
107) 
o Denied 
o ATC notification not 
required (Part 101-E) 
/ ATC authorization 
not required (Part 
107) 
Changes in authorization 
status prior to proposed flight 
(acceptance/authorization -> 
denial) 
Changes in authorization 
status during the proposed 
flight 
(acceptance/authorization -> 
termination) 


Cancellation of flight 
operation (prior to operation) e 


Message 
INTENT 


Change in flight operation 
end time (if operation ends 
earlier than originally 
planned; extension requires 
new request) 

Operator acknowledgement 
that flight operation will no 
longer be conducted (if 
initially accepted / authorized, 
then denied or terminated by 
ATC) 


Discussion 


field in the current UTM schema will be 
required. More information is needed to 
further define the flight denial 
challenge. There is no current field in 
the UTM research platform to support 
this. 


The various messages in the UTM 
research platform should be adaptable 
to the initial requirements of the FAA 
data exchange. Specific instances will 
need to be mapped out to determine 


any gaps. 


The goal of INTENT messages in the 
UTM research platform is to provide 
the system information from the 
operator on the state of the operation. 
This message type should be able to 
meet the FAA initial requirements. 
Specific instances will need to be 
mapped out to determine any gaps. 


11.6.4 Data Schema Comments 


For the other data fields that do not directly map to those suggested by the FAA, we propose to 
still include them in the demonstration under the current rules of the UTM research platform. As 
an example, we would require the inclusion of GCS location information even though there is 
not a direct mapping to the FAA elements because that is the current implementation of the 
UTM research platform. In the future, extraneous elements (as determined by this working 
group and the RTT as a whole) can be eliminated if needed. 


11.7 Schedule 


Table A-7 describes the schedule for executing the Collaborative Demonstration. 


Table A-7: Collaborative Demonstration Schedule 


Date Activity/Milestone/Deliverable Responsible Description 


Party 


17 Complete initial planning with full All 
Aug working group 


19 UTM DWG Collaborative NASA 
Aug Demonsiration Plan final draft 


23 ~~ Presentation/Discussion of UTM NASA 
Aug DWG Demonstration Plan to RTT 
2046 partners 


1 Initial information exchange All 
Sep architecture 


7 Collaborative Demonstration virtual All 
Sep meeting 


14 Finalize roles within the scenarios All 
Sep 
2016 


This date will be the final meeting day of the full 
working group. 


The final working draft of this document 
provided to all members of the working group. 
May continue to evolve to better represent the 
planning and implementation of the 
collaborative demonstration. 


A briefing to the larger RTT community on the 
activities, progress, and plans of the UTM 
DWG. Essentially a walkthrough of this 
document with relevant discussion targeted for 
stakeholders not directly involved in its 
formulation. 


A description of the system architecture that will 
support the collaborative demonstration. 


Tag-up to discuss progress. Scenarios should 
be finalized included the general roles of 
participants. The final working draft of the data 
schemas to support the collaborative 
demonstration should be a product of this 
meeting. 


Each participant will have clearly defined roles 
for participation within the scenarios. These 
roles will define, for example, the type of 
operation(s) that the participant will be 
responsible for portraying within the scenario. 
The interaction/timing of the roles/operation will 
be defined as well. For example, participant A 
submits operation X at t=3, participant B 
submits operation Y at t=5, FIMS issues 
message Q at time=8, etc. Note that some 
scenarios will not necessarily have precisely 
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Date Activity/Milestone/Deliverable 


28 
Sep 
2016 


TBD 


TBD 
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Initial FIMS instance available to 
external partners for testing 


Partner checkout sheet provided 


Checkout process complete 


Collaborative Demo Shakeout 


Collaborative Demo 


Responsible Description 


Party 


NASA 


NASA 


Partners 


All 


All 


defined times in order to more naturally 
simulate how interactions may occur while 
other scenarios will necessarily have scripted 
time triggers in order to capture interactions 
that might not otherwise be exercised or 
properly measured/observed. 


Based on the architecture decided on 1 Sep 
2016, a reasonable subset will be implemented 
and available for testing data exchange. 


To ensure all participants are building to the 
same specification for the demonstration, 
NASA will provide a testing specification and 
checkout process for partner systems. 


All partners need to adequately complete the 
checkout process by this date to continue 
participation in the collaborative demonstration. 
Run through the scenarios as a group to 
shakeout any issues. 


Execute the UTM DWG Collaborative 
Demonstration 


12 Appendix B - DWG Demonstration 1 Test Details 


The content of this appendix was originally a stand-alone document. The information contained 
herein represents the main guiding documentation for the execution of the demonstration. This 
document was kept on a NASA-internal website that was frequently updated and occasionally 
exported for sharing with external partners. This set of test details grew from the original 
information presented in Appendix A. 


12.1 Overview 


This document details the testing that will occur as part of the Data Exchange Working Group 
(DWG) Demonstration 1. An individual test is related to a single operator interacting with the 
Flight Information Management System (FIMS). Each test maps to a particular scenario as 
described in the DWG Demonstration 1 Plan. Each step in a test illustrates a single data 
exchange. Sets of tests may be performed simultaneously in a single experiment. The rest of 
this document describes some of the testing logistics and then the data exchanges, tests, and 
experiments. 


12.2 Participants 


The following organizations are participating in this demonstration (Table B-1). The 
abbreviations will be used for reference in the test planning. 


Table B-1: Participating Organizations 


Organization Abbreviation Primary Contact Email Phone 
NASA NASA Joseph Rios joey.rios@nasa.gov 

AirMap AIRM 7 : 

Amazon AMZN - - 

ANRA Technologies ANRA : : 

Simulyze SIMU 7 . 

Transtrex TRTX - . 


12.3 Schedule 


The Demonstration will take place over several non-consecutive dates. The nominal schedules 
for those dates are as follows: 


12.3.1 4th Nov 2016 


Table B-2: 4th Nov 2016 Demonstration 


Time (Pacific) Activity 

0900 Telecon setup 

0910 Roll call 

0915 Practice submissions, debugging 
1000 D1ix1 

1100 D1X2 

1200 Conclude 
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12.3.2 14th Nov 2016 


Table B-3: 14th Nov 2016 Demonstration 


Time (Pacific) Activity 

0900 Telecon setup 

0910 Roll call 

0915 Practice submissions, debugging 
0945 D1X3 

1030 D1X4 

1115 D1X5 

1200 D1ix6 

1245 Conclude 


12.3.3 17th Nov 2016 
Table B-4: 17th Nov 2016 Demonstration 


Time (Pacific) Activity 
TBD TBD 


12.4 Location 


The testing will be completed remotely. The FIMS role will be filled by NASA Ames Research 
Center (ARC) by hosting a server reachable by the other participants. The other participants 
will connect remotely to the FIMS for data exchange. The other participants will not need to 
connect to each other in any way. Each participant may offer connections to data for monitoring 
and visualization of the Demonstration. 


Throughout the test, there will be an ongoing telecon for communications. In addition, there will 
be an ongoing video conference for coordination and communication. Only the participants will 
be on the video conference, but the telecon may be open to nonparticipants. The telecon and 
the video conference will be recorded. 


12.5 Architecture 


The architecture for this activity is not to be assumed to be the architecture of any future 
system. This architecture is mostly based on previous Unmanned Aircraft Systems Traffic 
Management (UTM) work by NASA. 


The FIMS and the Operator will build to a known application programming interface (API). 
The API will use a RESTful architecture for submitting and requesting data in a synchronous 
way to and from the FIMS (Figure B-1). This RESTful API will be described in an OpenAPI 
Specification file. For asynchronous messages, WebSockets will be used. All data exchanges 
will be over port 443 on the FIMS. 
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FIMS 


ID 
<> 
Database Management 


tes 
Broker Application 
t 


Only open 
port is 443 


FIMS event-driven 
messages over secure 
web sockets 


Operation submissions, 
data requests, message 
sending via REST interface 


Operator 


Figure B-1: FIMS RESTful Architecture 


12.6 Assumptions 
In this section, we capture some of the assumptions of this test. 


12.7 Data Exchanges 


Table B-5 lists the individual data exchanges that are currently expected between FIMS and 
operators. This list will likely evolve as testing and discussions continue. For each data 
exchange, an identifier has been assigned. This identifier will allow for reference within the 
individual tests to ensure traceability. Most of these are taken from the provided Federal 
Aviation Administration (FAA) documentation. The rows highlighted in yellow are new data 
exchanges that may be needed to satisfy the identified scenarios. 


Table B-5: Data Exchanges 


Data Statement Data RESTful STOMP Applicatio Notes 
Exch Direc API Queue n/JSON 

ange tion Model 

ID 

D1E1 Flight Request Oper POST - Operation 


ator /operation 

to s (new 

FIMS_ operation) 
PUT 
/operation 
s/{gufi} 
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Data 
Exch 
ange 
ID 


D1E2 


D1E3 


D1iE4 


D1E5 


D1E6 


D1E7 
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Statement 


Indication if 
flight 
information is 
submitted too 
far in advance 
of operation 


Indication that 
flight 
information has 
been received 


Response to 
flight operation 
request: 
Accepted ( 
Part 101-E )/ 
Authorized 
(Part 107) 


Response to 
flight operation 
request: 
Denied 


Response to 
flight operation 
request: 

ATC 
notification not 
required (Part 
101-E)/ATC 
authorization 
not required 
(Part 107) 


Changes in 
authorization 
status prior to 
prior to 
proposed flight 
start time, as 
filed in the 
operation plan 
(acceptance/au 


Data 
Direc 
tion 


FIMS 
to 
Oper 
ator 


FIMS 
to 
Oper 
ator 


FIMS 
to 
Oper 
ator 


FIMS 
to 
Oper 
ator 
FIMS 
to 
Oper 
ator 


FIMS 
to 
Oper 
ator 


RESTful STOMP Applicatio Notes 
API Queue n/JSON 
Model 
(modify 
existing 
operation) 
- /user/{operator InformMes_ InformMessage 
Vdecision sage e PLAN SUBMITTED _TOO_EA 
RLY 
HTTP 201 - FIMSApiRe FIMSApiResponse 
response sponse e 201 
to POST e CREATED 
/operation e "some string (gufi?)" 
s 
- /user/{operator InformMes_ InformMessage 
Vdecision sage e ACCEPTED (Part 101-E) 
e AUTHORIZED (Part 107) 
- /user/{operator InformMes_ InformMessage 
Vdecision sage e DENIED 
- /user/{operator InformMes_ InformMessage 
Vdecision sage 5. NOTIFICATION _NOT_RE 
QUIRED (Part 101-E) 
6. AUTHORIZATION _NOT_R 
EQUIRED (Part 107) 
- /user/{operator InformMes_ InformMessage 
Vdecision sage 6. DENIED 


Data 
Exch 
ange 
ID 


D1E8 


D1E9 


D1E1 


D1E1 


D1E1 


Statement Data 


RESTful 


Direc API 


tion 


thorization -> 
denial) 


Changes in FIMS 
authorization to 
status during Oper 
the proposed ator 
flight start time, 

as filed in the 
operation plan 
(acceptance/au 
thorization -> 
termination) 


Cancellation of Oper 
flight operation ator 
(prior to to 
proposed FIMS 
operation start 

time) 

Change in flight Oper 
operation end ator 
time (if to 
operation ends FIMS 
earlier than 

originally 

planned; 

extension 

requires new 

request) 

Operator Oper 
acknowledgem ator 
ent that flight — to 


operation will FIMS 
no longer be 
conducted (if 

initially 

accepted / 
authorized, 

then denied or 
terminated by 

ATC) 

FIMS notifies FIMS 
operators of to All 
unplanned Oper 
deviation. ators 


POST 
/message 
s 


POST 
/message 
s 


POST 
/message 
s 


STOMP Applicatio Notes 
Queue n/JSON 
Model 


/user/{operator InformMes_ InformMessage 
Vdecision sage 1 TERMINATED 


- IntentMess IntentMessage 
age 1) CANCEL 


- IntentMess IntentMessage 
age 1) CLOSE 


- IntentMess IntentMessage: 
age D.1 ACK_NO_OPERATION 


/topic/emergen AlertMessa AlertMessage: 
cy ge E.1 OPERATIONS 
E.2 WARNING 
E.3 UNPLANNED_DEVIATION 
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Data 
Exch 
ange 


D1E1 


D1E1 


D1E1 
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Statement Data RESTful 
Direc API 
tion 

Operator - 

notifies FIMS of Oper 

unplanned ator 
deviation. in to 

course. FIMS 

FIMS notifies FIMS - 

operators of to 

airspace Oper 

constraint ator 

change. 

Operator Oper POST 

notifies FIMS of ator /message 

flight anomaly. to Ss 
FIMS 


Operator 

notifies FIMS 

that operation 

is back in 

conformance 

after anomaly. 

FIMS FIMS HTTP 201 - 
acknowledges to response 
receipt of Oper to POST 
anomaly ator /message 
message. s 


STOMP Applicatio 
Queue n/JSON 
Model 


/topic/constrai AlertMessa 
ntChange ge 


= AlertMessa 
ge 


sponse 


Notes 


E.4 maybe a free_text or warning 
element as well? 


Can this data exchange be 
accomplished with D1E15? 


For Scenario 2, this message 
notifies operators that the no-fly 
zones around the airport are 
changing or have changed. 

This can also take care of a 
dynamic constraint introduced due 
to an anomalous operation. 
AlertMessage: 

1 CONSTRAINT_CHANGE 


Anomalies may include, but 

wouldn't be limited to the following 

alert messages: 

AlertMessage: 

UNPLANNED_ LANDING 

UNCONTROLLED_ LANDING 

FLY_AWAY 

HIJACK 

OFF_COURSE 

UNPLANNED_ DEVIATION 

(Currently only sent from 

FIMS to Operator) 

7 Communications failure 
(between Operator and UAS)? 


OouahWN = 


AlertMessage: 
BACK_TO_CONFORMANCE 


FIMSApiRe FIMSApiResponse 


A Status Code 202 

B ACCEPTED 

C "Received notification of 
anomaly" 


Data Statement 


D1E1 Operator 

7 supplies 
position 
report(s). 
Operator 
supplies a 
single report 
or periodic 
reports, 
depending on 
FIMS request 
(see D1E18 
and D1iE19). 


D1E1 FIMS requests 
8 single position 
report. 


D1E1 FIMS requests 

9 repeated 
position 
reports. 


D1E2 FIMS cancels 

0 request for 
position 
reports. 


D1E2 Operator 

1 acknowledges 
that active 
operation has 
been 
cancelled/termi 
nated. 


12.8 Tests 


FIMS 
to 
Oper 
ator 


Oper 
ator 
to 
FIMS 


RESTful 
API 


POST 
/positions 


POST 


/message 


Ss 


STOMP Applicatio Notes 
Queue n/JSON 

Model 
3 Position 


/user/{operator AlertMessa AlertMessage: 


Vdecision ge 1 OPERATIONS 
2 WARNING 
3 POSITION _REPORT_REQU 
EST_SINGLE 


/user/{operator AlertMessa AlertMessage: 


Vdecision ge 1. OPERATIONS 
2. WARNING 
3: POSITION_REPORT_RE 


QUEST_CONTINUOUS 


/user/{operator AlertMessa AlertMessage: 


Vdecision ge 1. OPERATIONS 
2. WARNING 
3. POSITION _REPORT_RE 


QUEST_CANCEL 


- IntentMess IntentMessage 
age 1. ACK_NO_OPERATION 


Each table below represents a single test. Each test has a unique designator. That designator 
is a concatenation of the Demonstration number, scenario number, and test number. In 
addition, there may be a descriptive title associated with the test. For this demonstration, the 
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demonstration number is "1" for all tests. So, "D1S2T3" would indicate Demonstration 1, 
Scenario 2, Test 3. 


The tables are grouped by scenario, with a brief description of the scenario preceding the group 
of test tables. 


12.8.1 Scenario and Test Summary 
A summary of the scenarios is provided in Table B-6 below: 


Table B-6: Scenario Summary 


Scenario Scenario Name Scenario Description 

ID 

Scenario 0 Nominal Operations Scenario 0 exercises baseline data exchanges used during nominal 
operations. 


Scenario 1 Operator Incursion Scenario 1 demonstrates the handling of UAS incursions into 
unintended or unallocated regions. 


Scenario 2 Airspace Constraint | Scenario 2 demonstrates the creation and handling of no-fly zones. 
Change 
Scenario 3 All Land Scenario 3 demonstrates the issuing of "All Land" alerts to all 
operations. 


A summary of the tests is provided in Table B-7 below: 


Table B-7: Test Summary 


Scenario TestID Test Name Test Description Experiment 

ID 

Scenario DiSOT1 "NominalNoodle" Operator notifies D1ixX1 D1X2 D1X3 
0 FIMS of an operation 


that gets accepted; 
operation completes 
uneventfully. 


D1SOT2 "CancelledCarrot" Operator cancels an D1X1 
accepted operation 
before it begins. 

D1SOT3 "DenialDonut" FIMS denies a D1X1 
previously accepted 
operation, effectively 
cancelling it before it 
begins. 

D1SOT4 "TerminatedTomato" FIMS terminates an D1X2 
active operation. 

DiSOT5 "EarlyEwok" Operator notifies D1X1 


FIMS of an operation 
too far in advance of 
the operation. 
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Scenario TestID Test Name Test Description Experiment 
ID 


D1SOT6 "CompletedCucumber" Operator performsa D1X1D1X2 
nominal operation that 
completes earlier than 


planned. 

D1SOT7 "FlyAwayFigs" Operator notifies Dix2 D1X3 
FIMS of a fly-away 
operation. 

D1SOT8 "NegatoryNotify" Operator tries to notify D1ix2 


FIMS of operation, but 
the notification is not 
required. 

DiSOT9 "PaisleyPositions" FIMS requests D1X1 
position reports, then 
cancels request. 


D1S0T10 "WhereOne" FIMS requests a D1X2 
single position report. 
Scenario D1S1T1 "DeviatingDough" Operator has an D1X6 
1 unplanned deviation 


causing the FIMS to 
terminate that 
operation. 


D1SiT2 "RequestingRhubarb" Operator requests D1X6 
deviation through a 
no-fly zone that is 
denied. 


D1SiT3 "ReplanRadish" Operator requests D1X6 
deviation through a 
no-fly zone that is 
accepted. 


D1S1T5 "NoHarmNoFoul" Operator has an D1X6 
unplanned deviation, 
notifies FIMS and 
corrects course. 


D1S1T6 = "FixyFixy" Operator has an D1X6 
unplanned deviation, 
requests new plan 
and is accepted. 


D1SiT7 "NoSoupForYou" Operator has an D1X6 
unplanned deviation, 
requests new plan 
and is denied. 


Scenario D1S2T1 "NoFlyGuy" FIMS announces a D1X3 D1X5 
2 new no-fly zone 

affecting an active 

operation. 
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Scenario TestID Test Name Test Description Experiment 
ID 


D1S2T2 "FlippingFruit" FIMS announces a D1X5 
new no-fly zone 
affecting an active 
operation, operator 
requests new plan 
that is denied. 


D1S2T3 "GreatGoose" FIMS announces a D1ix5 
new no-fly zone 
affecting an active 
operation, operator 
requests new plan 
that is accepted. 


Scenario D1S3T1 "LandingLizards" FIMS issues an ‘all D1X4 
a land' directive, 
operator indicates 
when the operation 
has landed. 
D1S3T2 "LandingLoons" FIMS issues an ‘all D1X4 
land' directive, 
operator requests a 
new plan to land, 
FIMS accepts. 


12.8.2 Scenario 0 


The purpose of the tests described in Tables B-8 through B-17 below is to get a baseline of data 
exchange. These tests are not tied to a particular use case. 


Table B-8: NominalNoodle 
D1S0T1 


“NominalNoodle": Operator notifies FIMS of an operation that gets accepted; operation 
completes uneventfully. 


Step Action Actor Remarks Data 
Exchange 

1 Operator Flight Operator Operator requests a beyond visual line-of-sight D1E1 
Request (BVLOS) operation. 

2 Flight Request FIMS FIMS sends message to operator that flight request D1E3 
Received was received. 

3 Flight Request FIMS FIMS sends message to operator that flight request D1E4 
Accepted was accepted. 
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Table B-9: CancelledCarrot 


D1S0T2 

"CancelledCarrot": Operator cancels an accepted operation before it begins. 

Step Action Actor Remarks Data 

Exchange 

1 Operator Flight Operator Operator requests a BVLOS operation. D1E1 
Request 

2 Flight Request FIMS FIMS sends message to operator that flight request D1E3 
Received was received. 

3 Flight Request FIMS FIMS sends message to operator that flight request D1E4 
Accepted was accepted. 

4 Flight Cancelled Operator Operator sends cancellation message to FIMS. D1E9 

Table B-10: DenialDonut 
D1S0T3 


"DenialDonut": FIMS denies a previously accepted operation, effectively cancelling it before it 
begins. 


Step Action Actor Remarks Data 
Exchange 

1 Operator Flight Operator Operator requests a BVLOS operation. D1E1 
Request 

2 Flight Request FIMS FIMS sends message to operator that flight request D1E3 
Received was received. 

3 Flight Request FIMS FIMS sends message to operator that flight request D1E4 
Accepted was accepted. 

4 Flight Request Denied FIMS FIMS sends message to operator that the flight DIEy 

request was denied. 

5 Operator Operator Operator sends message to FIMS indicating that D1E11 

Acknowledgment operation will no longer take place. 


Table B-11: TerminatedTomato 


D1S0T4 

"TerminatedTomato": FIMS terminates an active operation. 

Step Action Actor Remarks Data 

Exchange 

1 Operator Flight Operator Operator requests a BVLOS operation. D1IE1 
Request 

2 Flight Request FIMS FIMS sends message to operator that flight request D1E3 
Received was received. 

3 Flight Request FIMS FIMS sends message to operator that flight request D1E4 
Accepted was accepted. 

4 Flight Request FIMS FIMS sends message to operator that flight request D1E8 


Terminated is terminated during operation. 


D1S0T4 
"TerminatedTomato": FIMS terminates an active operation. 


5 Operator Operator Operator sends message indicating that operation is D1E10 
Acknowledgment terminated and no longer flying. 


Table B-12: EarlyEwok 


D1S0T5 

“EarlyEwok": Operator notifies FIMS of an operation too far in advance of the operation. 

Step Action Actor Remarks Data 

Exchange 

1 Operator Flight Operator Operator requests a BVLOS operation. DiEi 
Request 

2 Flight Request FIMS FIMS sends message to operator that flight request was D1E3 
Received received. 


3 Flight Request FIMS FIMS sends message to operator that flight request was D1E2 
Accepted submitted too far in advance. 


Table B-13: CompletedCucumber 
D1SOT6 


"CompletedCucumber": Operator performs a nominal operation that completes earlier than 
planned. 


Step Action Actor Remarks Data 
Exchange 

1 Operator Flight Operator Operator requests a BVLOS operation. D1E1 
Request 

2 Flight Request FIMS FIMS sends message to operator that flight request D1E3 
Received was received. 

3 Flight Request FIMS FIMS sends message to operator that flight request D1E4 
Accepted was accepted. 

4 Flight Request Operator Operator sends message indicating that operation D1E10 
Terminated completed earlier than planned. 


Table B-14: FlyAwayFigs 


D1S0T7 

"FlyAwayFigs": Operator notifies FIMS of a fly-away operation. 

Step Action Actor Remarks Data 

Exchange 

1 Operator Flight Request Operator Operator requests a BVLOS operation. Diet 

2 Flight Request Received FIMS FIMS sends message to operator that DIES 
flight request was received. 

3 Flight Request Accepted FIMS FIMS sends message to operator that DiE4 


flight request was accepted. 
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D1SO0T7 


"FlyAwayFigs": Operator notifies FIMS of a fly-away operation. 


4 Operator Reports Fly-Away 


5 Report Received 


Operator Operator sends message indicating that 
operation is no longer under positive 
control. 


FIMS FIMS acknowledges report. 


6 FIMS Announces No-Fly Zone FIMS FIMS implements a no-fly zone that is 


7 FIMS Announces Unplanned 


Deviation 


expected to contain the fly-away vehicle. 


FIMS FIMS sends information to other 
operations about the unplanned deviation 


8 FIMS Requests Position Reports FIMS FIMS sends message to operator 


9 Operator Supplies Position 


Reports 


10 Operator Reports Flight 
Completion/Termination 


11. FIMS Announces Removal of No- FIMS 


Fly Zone 


D1SO0T8 


“NegatoryNotify": Operator tries to notify FIMS of operation, but the notification is not required. 


Step Action 


1 Operator Flight 


Request 

2 Flight Request 
Received 

3 Flight Request 
Unnecessary 

D1SO0T9 


Actor 


requesting continuous (1Hz) position 
reports. 


Operator Operator begins supplying position reports D1E17 


at 1Hz. 
Operator Operator sends message indicating when 
vehicle is known to have landed. 


hoc no-fly zone is removed. 


Table B-15: NegatoryNotify 


Remarks 


Operator Operator requests a line-of-sight (LOS) operation 


FIMS 


FIMS 


within Class. 


FIMS sends message to operator that flight 
request was received. 


FIMS sends message to operator that flight 
request was not required. 


Table B-16: PaisleyPositions 


"PaisleyPositions"”: FIMS requests position reports, then cancels request. 


Step Action 


1 Operator Flight 


Request 

2 Flight Request 
Received 

3 Flight Request 
Accepted 


Actor 


Operator 


FIMS 


FIMS 


Remarks 


Operator requests a LOS operation within Class. 


FIMS sends message to operator that flight request 
was received. 
FIMS sends message to operator that flight request 
was accepted. 


DiE10 


When fly-away is clear of airspace, the ad DiE14 


Data 
Exchange 
DIET 
D1E3 


DiE6 


Data 
Exchange 
D1E1 
D1E3 


D1E4 
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D1SO0T9 
"PaisleyPositions": FIMS requests position reports, then cancels request. 


4 FIMS Requests FIMS After the start time of the operation, the FIMS requests D1E19 


Positions continuous position reports. 

5 Operator Submits Operator Operator begins to send in position reports at 1Hz. D1E17 
Positions 

6 FIMS Cancels FIMS — After a couple of minutes of receiving position reports, D1E20 
Request FIMS cancels position report request. 


Table B-17: WhereOne 


D1S0T10 

“WhereOne": FIMS requests a single position report. 

Step Action Actor Remarks Data 

Exchange 

1 Operator Flight Operator Operator requests a LOS operation within Class. D1E1 
Request 

2 Flight Request FIMS FIMS sends message to operator that flight request D1E3 
Received was received. 

3 Flight Request FIMS FIMS sends message to operator that flight request D1E4 
Accepted was accepted. 

4 FIMS Requests FIMS _ After the start time of the operation, the FIMS D1E18 
Position requests a single position report. 

5 Operator Submits |§ Operator Operator sends a single position report. D1E17 
Positions 


12.8.3 Scenario 1 

The tests described in Tables B-18 through B-23 exercise the ability of the data exchanges to 
handle cases wherein there is an incursion of an operation into a region that is not typically 
allocated for use by that operation. To illustrate this scenario, we use National Park boundaries, 
which have been traditionally off-limits to commercial and hobby drone use. 


Table B-18: DeviatingDough 


D1S1T1 
"DeviatingDough": Operator has an unplanned deviation causing the FIMS to terminate that 
operation. 
Step Action Actor Remarks Data 
Exchange 
1 Operator Flight Request Operator Operator requests a BVLOS operation skirtinga DiE1 
National Park boundary. 


2 Flight Request Received FIMS FIMS sends message to operator that flight D1E3 
request was received. 
3 Flight Request Accepted FIMS FIMS sends message to operator that flight D1E4 
request was accepted. 
4 Operator Notifies of Operator Operator sends message to FIMS that operation DiE15 
Deviation is off course. 
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D1S1T1 


“"DeviatingDough": Operator has an unplanned deviation causing the FIMS to terminate that 


operation. 
5 FIMS Acknowledges FIMS FIMS indicates that the deviation message was 
received. 
6 Flight Request FIMS FIMS cancels the original flight request due to 
Terminated inability to maintain accepted plan. 


7 FIMS Requests Position FIMS FIMS sends message to operator requesting 


Reports continuous (1Hz) position reports. 

8 Operator Supplies Operator Operator begins supplying position reports at 
Position Reports 1Hz. 

9 Flight Request Operator Operator acknowledges receipt of the the flight 
Termination Received termination request. 

10 Flight Termination Operator Operator sends message when flight is 
Complete successfully terminated. 


Table B-19: RequestingRhubarb 


Data 
Exchange 
D1E1 
D1E3 


DiE4 


D1S1T2 

“"RequestingRhubarb": Operator requests deviation through a no-fly zone that is denied. 

Step Action Actor Remarks 

1 Operator Flight Operator Operator requests a BVLOS operation skirting a 
Request National Park boundary. 

2 Flight Request FIMS FIMS sends message to operator that flight request 
Received was received. 

3 Flight Request FIMS FIMS sends message to operator that flight request 
Accepted was accepted. 


4 Operator Requests Operator Operator sends message to FIMS requesting new 


Deviation 
5 FIMS Acknowledges FIMS 


6 Deviation Request FIMS 


Denied continue with the originally accepted flight plan. 
Table B-20: ReplanRadish 

D1S1T3 

"ReplanRadish": Operator requests deviation through a no-fly zone that is accepted. 

Step Action Actor Remarks 

1 Operator Flight Operator Operator requests a BVLOS operation skirting a 
Request National Park boundary. 

2 Flight Request FIMS FIMS sends message to operator that flight request 
Received was received. 


plan through nominal no-fly zone (National Park). 


FIMS indicates that the deviation request message 
was received. 


FIMS denies the request, leaving the operator to 


DiE1 


Data 
Exchange 
D1E1 


DiE3 
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D1S1T3 
“ReplanRadish": Operator requests deviation through a no-fly zone that is accepted. 


3 Flight Request FIMS FIMS sends message to operator that flight request D1E4 
Accepted was accepted. 

4 Operator Requests Operator Operator sends message to FIMS requesting new D1E1 
Deviation plan through nominal no-fly zone (National Park). 


5 FIMS Acknowledges FIMS FIMS indicates that the deviation request message D1E3 
was received. 


6 Deviation Request FIMS FIMS accepts the requested deviation. D1E4 
Accepted 

7 Flight Request Operator Operator sends message indicating operation D1E10 
Terminated completes the new plan early. 


D1S1T4 REMOVED AS DUPLICATION. 
Table B-21: NoHarmNoFoul 


D1S1T5 "NoHarmNoFoul": Operator has an unplanned deviation, notifies FIMS, corrects course. 


Step Action Actor Remarks Data 
Exchange 


1 Operator Flight Request Operator Operator requests a BVLOS operation skirtinga D1E1 
National Park boundary. 


2 Flight Request Received FIMS FIMS sends message to operator that flight D1E3 
request was received. 
3 Flight Request Accepted FIMS FIMS sends message to operator that flight D1E4 


request was accepted. 
4 Operator Notifies of Operator Operator sends message to FIMS that operation D1E15 


Deviation is off course. 
5 FIMS Acknowledges FIMS FIMS indicates that the deviation message was DI1E3 
received. 
6 Operator Notifies of Operator Operator indicates the operation is now backin D1E15 
Correction conformance. 
7 FIMS Acknowledges FIMS FIMS indicates that the correction message was DiE3 
received. 
8 FIMS Requests Position FIMS FIMS requests one position report to help verify D1E18 
Report flight is back on course. 
9 Operator Supplies Operator Operator sends in a single position report to the D1E17 
Position FIMS. 
10 Flight Termination Operator Operator sends message when flight is D1E10 
Complete successfully terminated. 


Table B-22: FixyFixy 


Data 
Exchange 


DiE1 


D1S1T6 

“FixyFixy": Operator has an unplanned deviation, requests new plan and is accepted. 

Step Action Actor Remarks 

1 Operator Flight Operator Operator requests a BVLOS operation skirting a 
Request National Park boundary. 

2 Flight Request FIMS FIMS sends message to operator that flight 
Received request was received. 

3 Flight Request FIMS FIMS sends message to operator that flight 
Accepted request was accepted. 

4 Operator Notifies of Operator Operator sends message to FIMS that operation is 
Deviation off course. 

5 FIMS Acknowledges  FIMS FIMS indicates that the deviation message was 

received. 

6 Operator Requests Operator Plan modification requested that is compatible with 
Deviation the unplanned deviation. 

7 FIMS Acknowledges  FIMS FIMS indicates that the plan request was received. D1E3 

8 FIMS Accepts FIMS FIMS accepts the requested deviation. 
Deviation 


Table B-23: NoSoupForYou 


D1S1T7 


“NoSoupForYou": Operator has an unplanned deviation, requests new plan and is denied. 


Step Action Actor Remarks 


1 Operator Flight Request Operator Operator requests a BVLOS operation skirting a 
National Park boundary. 


2 Flight Request Received FIMS FIMS sends message to operator that flight 
request was received. 

3 Flight Request Accepted FIMS FIMS sends message to operator that flight 
request was accepted. 


4 Operator Notifies of Operator Operator sends message to FIMS that operation 
Deviation is off course. 
5 FIMS Acknowledges FIMS FIMS indicates that the deviation message was 
received. 
6 Operator Requests Operator Plan modification requested that this compatible 
Deviation with the unplanned deviation. 
7 FIMS Acknowledges FIMS FIMS indicates that the plan request was 
received. 
8 FIMS Denies Deviation FIMS FIMS denies the requested deviation. 
Request 


Data 
Exchange 


DiE1 
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12.8.4 Scenario 2 
Tables B-24 through B-26 describe Scenario 2. 


D1S2T1 
“NoFlyGuy”: FIMS announces a new no-fly zone affecting an active operation. 


Step Action 


Table B-24: NoFlyGuy 


Actor Remarks 


Operator Flight | Operator Operator requests a BVLOS operation near airport in an 


Request allowed region. 

2 Flight Request FIMS FIMS sends message to operator that flight request was 
Received received. 

3 Flight Request FIMS FIMS sends message to operator that flight request was 
Accepted accepted. 

4 No-Fly Zone FIMS FIMS announces that the airspace configuration is 
Notification changing: new no-fly zone added which affects the active 

operation. 

5 Flight Request | Operator Operator sends message indicating operation completes 

Terminated the plan early. 
Table B-25: FlippingFruit 
D1S2T2 


Data 
Exchange 


DiE1 


"FlippingFruit": FIMS announces a new no-fly zone affecting an active operation, operator 
requests new plan that is denied. 


Step Action 

1 Operator Flight 
Request 

2 Flight Request 
Received 

3 Flight Request 
Accepted 

4 No-Fly Zone 
Notification 

5 Operator Requests 
Deviation 

6 Deviation Request 
Denied 

7 Flight Request 


46 


Terminated 


Actor Remarks 


Operator Operator requests a BVLOS near airport in an allowed 
area. 


FIMS FIMS sends message to operator that flight request 
was received. 


FIMS FIMS sends message to operator that flight request 
was accepted. 


FIMS FIMS announces airspace configuration is changing 
with a no-fly zone affecting operation. 


Operator Operator requests new plan to vacate the new no-fly 
zone. 


FIMS FIMS denies the requested deviation. 


Operator Operator sends message indicating operation 
completes the plan early. 


Data 
Exchange 


D1E1 


D1S2T3 


Table B-26: GreatGoose 


"GreatGoose": FIMS announces a new no-fly zone affecting an active operation, operator 
requests new plan that is accepted. 


Step Action 


1 Operator Flight 
Request 

2 Flight Request 
Received 

3 Flight Request 
Accepted 

4 No-Fly Zone 
Notification 


Actor 


FIMS 


FIMS 


FIMS 


Remarks 


Operator Operator requests a BVLOS near airport in an allowed 


area. 


FIMS sends message to operator that flight request 
was received. 
FIMS sends message to operator that flight request 
was accepted. 


FIMS announces that the airspace configuration is 
changing with a no-fly zone affecting operation. 


5 Operator Requests Operator Operator requests new plan to vacate the new no-fly 


Deviation 


6 Deviation Request 


Accepted 


12.8.5 Scenario 3 


FIMS 


zone. 
FIMS accepts the requested deviation. 


Tables B-27 and B-28 describe Scenario 3. 


D1S3T1 


Table B-27: LandingLizards 


Data 
Exchange 
D1E1 
DIES 


DiE4 


“LandingLizards": FIMS issues an ‘all land' directive, operator indicates when the operation has 


landed. 
Step Action 


1 Operator Flight 


Request 

2 Flight Request 
Received 

3 Flight Request 
Accepted 

4 Flight Request 
Terminated 

5 Operator 


Acknowledgment 


Actor 


Remarks 


Operator Operator requests a BVLOS operation. 


FIMS 


FIMS 


FIMS 


FIMS sends message to operator that flight request 
was received. 

FIMS sends message to operator that flight request 
was accepted. 

FIMS sends message to operator that all operations 
must land. 


Data 
Exchange 


D1E1 
D1E3 


D1E4 


D1E8 


Operator Operator sends message indicating that operation is D1E10 


terminated and no longer flying. 
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Table B-28: LandingLoons 


D1S3T2 
“LandingLoons": FIMS issues an ‘all land’ directive, operator requests a new plan to land, FIMS 
accepts. 


Step Action Actor Remarks Data 
Exchange 

1 Operator Flight Operator Operator requests a BVLOS operation. D1E1 
Request 

2 Flight Request FIMS FIMS sends message to operator that flight request D1E3 
Received was received. 

3 Flight Request FIMS FIMS sends message to operator that flight request D1E4 
Accepted was accepted. 

4 Flight Request FIMS FIMS sends message to operator that all D1E8 
Terminated operations must land. 

5 Operator Requests Operator Operator requests plan that complies with land now D1E1 
Deviation directive. 

6 Flight Request FIMS FIMS sends message to operator that flight request D1E3 
Received was received. 

7 Flight Request FIMS FIMS sends message to operator that flight request D1E4 
Accepted was accepted. 

8 Operator Operator Operator sends message indicating that operation D1E10 
Acknowledgment is terminated and no longer flying. 


12.9 Experiments 


Each experiment is comprised of one of more tests. The experiments may be performed 
multiple times to either verify certain concepts or integrate multiple participants in different roles. 
The experiments are labeled D1 (for Demonstration 1), followed by 'X' and a number. For each 
run of an experiment there may be a different configuration. For example, different participants 
may take different roles, or some starting assumptions may be altered. For each experiment 
below, we list the planned configurations. A summary of the six experiments is provided in Table 
B-29 below: 


Table B-29: Experiments 


Experiment Title Description 

ID 

D1ix1 Nominal 1 Run through six non-fly-away tests. 

D1X2 Nominal 2 Show nominal operations unaffected by a fly-away operation. 

D1X3 Fly-Away Exercise Show operations affected by a fly-away operation. 

D1xX4 All Land Demonstrate notification of an all-land instruction from FIMS. 

D1X5 Airport Configuration Demonstrate a change in the airspace relative to no-fly zones. 
Change 

D1X6 Operator Incursion Demonstrate interactions between operators and FIMS during 


incursions to a no-fly zone. 
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12.9.1 D1X1: Nominal 1 


In this experiment, we run the six non-fly-away, nominal scenarios in parallel. The roles for the 
operators are rotated through the six tests, so there are six configurations (Table B-30). For 
timing purposes, at T=0, the FIMS is verified to be operational and reachable. The Test Director 
then announces "All Tests are GO" at which point each participant is free to execute the 
assigned test for that configuration per the experiment sequence described in Table B-31. 


12.9.1.1 Configurations 


Table B-30: "Nominal 1" Configurations 


Configuratio D1S0T1 D1SO0T2 D1SOT3 D1S0T9 D1SOT5 D1SO0T6 

n 
NominalNoodl CancelledCarr DenialDon PaisleyPosition EarlyEwo CompletedCucumb 
e ot ut Ss k er 

A AIRM TRTX SIMU NASA ANRA = AMZN 

B AMZN AIRM TRTX SIMU NASA ANRA 

C ANRA AMZN AIRM TRTX SIMU NASA 

D NASA ANRA AMZN AIRM TRTX SIMU 

E SIMU NASA ANRA AMZN AIRM TRTX 

F TRTX SIMU NASA ANRA AMZN AIRM 


12.9.1.2 Sequence 


Table B-31: "Nominal 1" Sequence 


Step Time Action Notes 
(min:sec) 
1 T=0:00 Command Center calls 'mark.' Potential countdown prior to 'mark.' 
2 0:00 to 0:30 Operators submit plans. Start time between T+30seconds and 
T+1min. 


Duration at least 2 minutes. 
3 0:30 to 1:00 Operators commence simulated 


operations. 

4 1:00 to 1:30 = FIMS makes position report request per 
D1iS0T9. 

5 1:30 to 2:00 = FIMS cancels request per D1SOT9. 

6 2:00 Tests completes. 

7 ig Experiment completes. 


12.9.2, D1X2: Nominal 2 


The fly-away test (D1SOT7 "FlyAwayFigs") is exercised here. One operator reports a fly-away 
while the other five operators are executing nominal scenarios. The assumptions in this 
experiment include: 

iP 

e None of the nominal tests are operating near the fly-away. 

e None of the nominal tests alter their plans based on the fly-away. 
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The no-fly zone implemented based on the fly-away does not intersect any of the nominal 
operations. 


Each participant takes the fly-away role once, allowing for six runs of this experiment (Table B- 
32). The experiment sequence is described in Table B-33. 


12.9.2.1 Configurations 


Table B-32: "Nominal 2" Configurations 


Configuratio DiSOT7 D1SO0T1 D1S0T10 DiSOT6 D1SO0T8 D1SOT4 


n 


7aAMmMoO WwW > 


FlyAwayFig NominalNood! WhereOn CompletedCucumb NegatoryNoti TerminatedToma 


s e e 
AIRM TRTX SIMU 
AMZN AIRM TRIX 
ANRA AMZN AIRM 
NASA ANRA AMZN 
SIMU NASA ANRA 
TRIX SIMU NASA 


The fly-away operation will follow this plan: 


er fy to 
NASA ANRA AMZN 
SIMU NASA ANRA 
TRIX SIMU NASA 
AIRM TRIX SIMU 
AMZN AIRM TRTX 
ANRA AMZN AIRM 


https://gist. github.com/alotau/9206e45fdc6803a0efa62f20f749a552. 


The plans for all the tests in this experiment may file any other appropriate plans for that test 
such that those plans are well clear of the fly-away plan. 


12.9.2.2 Sequence 


Table B-33: "Nominal 2" Sequence 


Step Time Action 
(min:sec) 

1 T=0:00 Command Center calls 'mark.' 

2 0:00 to 0:30 Operators submit plans. 

3 0:30 to 1:00 Operators commence simulated 
operations. 

4 1:00 FIMS sends request for single 
position report (D1SOT10 - 
WhereOne). 

5 1:00 to 1:30 Per DiSOT7, operator sends fly- 
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away message to FIMS. 
FIMS issues no-fly zone 
announcement. 


Notes 


Potential countdown prior to 'mark.' 


Start time between T+30seconds and T+1min. 
Duration at least 3 minutes. 


The fly-away message should be sent by the 
operator upon their first position report outside 
their planned area. 

We could issue a fly-away message earlier than 
that, assuming the operator would know about 
loss of command earlier. 


Step Time Action Notes 


(min:sec) 

6 > 2:00 Per D1SOT7, operator continues to 
landing location at constant altitude 
then lands. 

Other operations (all unaffected by 
fly-away) complete their operations, 

7 * Experiment completes. 


12.9.3, D1X3: Fly-Away Exercise 

This experiment allows for D1SOT7 (FlyAwayFigs) to interact with active plans by other 
operators. This implies the affected operators are clearing the newly created no-fly zone and 
providing appropriate messages to the FIMS. In the configuration table (Table B-34), those 
operators tagged as "affected" will have a plan that intersects the fly-away no-fly zone. The 
others are not affected. 


12.9.3.1 Configurations 
Table B-34: D1X3 Configurations 
Configuration D1SOT7 D1S2T1 D1S2T1 D1S2T1 D1S0T1 D1S0T1 


Trajectory Volume1 Volume2 Unaffected 1 Unaffected 2 
FlyAwayFigs NoFlyGuy NoFlyGuy NoFlyGuy NominalNoodle NominalNoodle 


A AIRM TRIX SIMU NASA ANRA AMZN 
B AMZN AIRM TRTX SIMU NASA ANRA 
Cc ANRA AMZN AIRM TRIX SIMU NASA 
D NASA ANRA AMZN AIRM TRIX SIMU 
E SIMU NASA ANRA AMZN AIRM TRTX 
F TRIX SIMU NASA ANRA AMZN AIRM 


Details for each of the plans are provided at 


https://gist. github.com/alotau/2409eda1f1c6d80d5da313a0c511c4f5. 


These plans are illustrated in Figure B-2 below. The fly-away operation is in orange, the 
affected operations are in blue, and the unaffected operations are in brown. The fan-shaped 
FIMS-generated no-fly zone is in red. 
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Figure B-2: D1X3 Operation Plans 


12.9.3.2 Sequence 


The experiment will begin on the mark of the Command Center and will be considered "T=0" for 
the experiment and then progress as detailed in Table B-35 below: 


Step Time 
(min:sec) 

1 T=0:00 

2 0:00 to 
0:30 

3 0:30 to 
1:00 

4 1:00 to 
1:30 

5 > 1:30 
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Table B-35: D1X3 Sequence 


Action Notes 
Command Center calls 'mark.' Potential countdown prior to 'mark.' 
Operators submit plans. Start time between T+30seconds and T+1min. 


Duration at least 10 minutes. 
Operators commence simulated 


operations. 

Per D1SOT7, operator sends fly-away The fly-away message should be sent by the 
message to FIMS. operator upon their first position report outside 
FIMS issues no-fly zone their planned area. 

announcement. We could issue a fly-away message earlier 


than that, assuming the operator would know 
about loss of command earlier. 

Per D1SO0T7, operator continues to 

landing location at constant altitude 

then lands. 


Step Time Action Notes 


(min:sec) 
Affected operations (D1S2T1) safely 
land ASAP while staying within 
planned operation area. 
6 * Experiment completes. 


12.9.4 D1X4: All Land 


This experiment exercises Scenario 3 wherein all small unmanned aircraft system (SUAS) 
operations are ordered to "land now." There are two modes of operation that we are testing in 
terms of the operator response to this directive. First, the operator just figures out a safe way to 
land then executes that landing, finally indicating to the FIMS that the operation is complete. 
Second, the operator may plan a new path to safely terminate, submit that plan to the FIMS for 
acceptance, then execute (assuming acceptance is granted). Note that there are other 
information flows that may be equally valid and perhaps better for the concept, but we will only 
exercise these two options. Other options may include the requirement that such contingency 
plans are part of the original flight request, or that all operations literally go to ground ASAP from 
the time receiving the directive, and there could be others. 


12.9.4.1 Configurations 

Note that in Table B-36 we indicate the test that is run together with a label for the expected 
initial plan. The initial plans are detailed after the table. For example, in the set of initial plans, 
one is labeled as "B" so each test in the table that references "B" would use that plan with that 
test. 
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Table B-36: D1X4 Configurations 


Configuration a B 7 fo) 
D1iS3T1 DiISsTl D1S3T1 D1iS3T1 
LandingLizards LandingLizards LandingLizards LandingLizards 

A AIRM SIMU NASA AMZN 
D1S3T2 D1S3T2 D1S3T2 D1S3T2 
LandingLoons LandingLoons LandingLoons LandingLoons 

B SIMU AIRM TRIX NASA 
D1S3T1 D1S3T1 D1S3T2 D1S3T2 
LandingLizards LandingLizards LandingLoons LandingLoons 

Cc ANRA NASA AMZN TRIX 

D AMZN TRIX SIMU ANRA 


Details for each of the plans illustrated in Figure B-3 below are provided at 
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https://gist.github.com/alotau/223fc7bca3d7eb93678868208b6f5484. 


Figure B-3: D1X4 Operation Plans 


12.9.4.2 Sequence 


The experiment will begin on the mark of the Command Center and will be considered "T=0" for 
the experiment and then progress as detailed in Table B-37 below: 


Table B-37: D1X4 Sequence 


Step Time Action Notes 
(min:sec) 
1 T=0:00 Command Center calls 'mark.' Potential countdown prior to 'mark.' 
2 0:00 to 0:30 Operators submit plans. Start time between T+30seconds and 
T+1min. 


Duration at least 10 minutes. 

3 0:30 to 1:00 Operators commence simulated operations. 

4 1:00 to 1:30 FIMS issues “all land" directive. Is there a maximum time associated 
with the need to land? 


5 > 1:30 LandingLoons (D1S3T2) group issues new 
plan to execute landing. 
LandingLizards (D1S3T1) land safely within 
operational plan. 


6 i Experiment completes. 


12.9.5 D1X5: Airport Configuration Change 


This experiment exercises Scenario 2 wherein an airport changes its configuration, which affects 
nearby SUAS operations by removing a no-fly zone and adding a different no-fly zone. This 
scenario and experiment is undertaken with the understanding that some of the underlying 
National Airspace System (NAS) data that would be required to implement such a scenario may 
not be easily available. Specifically, the dissemination of airport configurations are not 
necessarily part of the current NAS. 


San Jose International airport (SUC) is known to have two major configurations, a south flow 
configuration and a north flow configuration. The north flow is the nominal configuration. 
However due to weather/wind or coordination with other airports (SFO and OAK) in the Bay- 
area metroplex, there may be a need to switch to a south flow. Often this is planned, but the 
lead time to complete the configuration may be relatively short. To bound this experiment, we 
choose the artificial value of 10 minutes to allow all SUAS to clear the approach side of the 
airport when the configuration change is being implemented. More specifically, from the time 
that the configuration change is announced via the FIMS to Operators, all operations must 
cease operations in the new no-fly zone, while operations may commence in the newly freed 
no-fly zone from the other side of the airport. 


The airspaces to be used in this experiment are detailed here: 


https://gist. github. com/alotau/bfb98a6d372b0c2 1 bacfc88 1f88581b7. 


These are illustrated in Figure B-4 below: 
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Figure B-4: D1X5 Operation Plans 


12.9.5.1 Configurations 
The configurations for this experiment are listed in Table B-38 below: 


Table B-38: D1X5 Configurations 


Configuration D1S2T1 D1S2T1 D1S2T2 D1S2T2 D1S2T3 D1S2T3 
NoFlyGuy NoFlyGuy  FlippingFruit FlippingFruit GreatGoose GreatGoose 

A AIRM TRTX SIMU NASA ANRA AMZN 

B ANRA AMZN AIRM TRTX SIMU NASA 

C SIMU NASA ANRA AMZN AIRM TRTX 


12.9.5.2 Sequence 


The experiment will begin on the mark of the Command Center and will be considered "T=0" for 
the experiment and then progress as detailed in the Table B-39 below: 


Table B-39: D1X5 Sequence 


Step Time Action Notes 
(min:sec) 
1 T=0:00 Command Center calls 'mark.' Potential countdown prior to 
‘mark.’ 
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Step Time Action Notes 
(min:sec) 
2 0:00 to 0:30 Operators submit plans. Start time between 
T+30seconds and T+1min. 
Duration at least 10 minutes. 


3 0:30 to 1:00 Operators commence simulated operations. 


4 1:00 to 1:30 FIMS issues constraint change. Is there a maximum time 
associated with the need to 
land? 

5 > 1:00 FlippingFruit (D1S2T2) and GreatGoose (D1S2T3) 


groups request new plans and receive appropriate 
responses from FIMS. 
All participants complete their plans. 


6 id Experiment completes. 


12.9.6 D1X6: Operator Incursion 


This experiment exercises Scenario 1, wherein an operation unintentionally enters a no-fly zone. 
In this scenario, the no-fly zone is a National Park area that is nominally off-limits to SUAS 
operations. Two National Historic Sites will be used in this experiment: John Muir National 
Historic Site and the William Howard Taft National Historic Site. The boundaries of these sites are 
provided as a GitHub gist. 


12.9.6.1 Configurations 
The configurations for this experiment are listed in Table B-40 below: 


Table B-40: D1X6 Configurations 


Configuratio Muir Muir Muir Taft Taft Taft 
n DiS17T1 DiS1T2 D1S1T3 D1iS1T5 D1S1T |DiS1T7 
6 
DeviatingDoug RequestingRhubar ReplanRadis NoHarmNoFo_ FixyFix NoSoupForYo 
h b h ul y u 
A AIRM TRTX SIMU NASA ANRA AMZN 
B AMZN AIRM TRTX SIMU NASA ANRA 
C ANRA AMZN AIRM TRTX SIMU NASA 


12.9.6.2 Sequence 


The experiment will begin on the mark of the Command Center and will be considered "T=0" for 
the experiment and then progress as detailed in Table B-41 below: 


Table B-41: D1X6 Sequence 


Step Time Action Notes 

(min:sec) 
1 T=0:00 Command Center calls 'mark.' Potential countdown prior to 'mark.' 
2 0:00 to 0:30 Operators submit plans. DiS17T1 & D1S1T5: Start time 


between T+30seconds and T+1min. 
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Step Time Action Notes 
(min:sec) 

D1SiT2 & D1S1T6: Start time 
between T+3min and T+4min. 
D1S1T3 & D1S1T7: Start time 
between T+6min and T+7min. 
All durations between 2 and 4 
minutes. 
All departures and initial plans very 
near the respective national park 
boundary. 


3 0:30 to 1:00 D1Si1T1 & D1S1T5: Operations commence. 


4 1:30 to 1:50 Step 4 (Operator Notifies of Deviation) of test is 
executed. 
FIMS sends cancel/termination message to 
D1S17T1. 
Per D1S11T5, operator sends message 
indicating flight correction. 
FIMS requests positions from operator per 
D1iS1T1 & D1S1T5 (continuous and single, 
respectively). 
Per D1S111, operator acknowledges receipt of 
the the termination request. 


5 2:30 DiS1T1 & D1S1T5: Operations complete. 
6 3:00 to 4:00 D1S1T2 & D1S1T6: Operations commence. 
7 5:00 DiSi1T2 & D1S1T6: Operations make their 


respective requests to FIMS. 
FIMS sends appropriate responses. 


8 5:30 D1Si1T2 & D1iS1T6: Operations complete. 

9 6:00 to 7:00 D1S1T3 & D1S1T7: Operations commence. 

10 7:00 to 9:00 D1S1T3 & D1S1T7: Complete test steps. Need to complete with more detail for 
these last two operations. 

i” Experiment completes. 


12.10 Data Exchange Test Coverage 

In this section, the individual data exchanges are mapped to the tests and experiments in which 
they are invoked. This will establish a minimal coverage of the data exchanges under test. As 
this document has been evolving, it may be that each test or experiment that would cover a data 
exchange is not listed, however since the goal of Table B-42 below is to establish minimum 
coverage of the data elements, these potential omissions are acceptable. 
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Data 
Exchange 


Diet 
DiE2 
DIE3 
D1E4 
DIE5 
D1E6 


Table B-42: Data Exchange Test Coverage 


Tests 


ALL 

D1SOT5 

ALL (except for DiSOT5, D1SOT8) 

ALL 

DiS2T2, DiS1T7, D1S2T2 

D1SOT8 

D1S0T3 

D1iSOT4, D1S1T1, D1S3T1, D1S3T2 

D1S0T2 

D1S0T4, D1S0T6, D1SOT7, D1S1T1, D1S1T3, 


D1S1T5, DiS2T1, D1S2T2, D1S3T1, D1S3T2 
D1iSO0T3 
DiSOT7 


N/A 


D1SOT7, D1iS2T1, D1S2T2, D1S2T3 


D1iS0T10, D1S1T5 
DiSOT7, DiSOT9, D1S1T1 
D1iSOT9 

DiSiT1 


Experiments 


ALL 
D1xX1 
ALL 
ALL 


D1X3, D1X5 
D1X2, D1X3 


D1X2, D1X3, D1X6 


D1X1, D1X2, D1X3 


D1X1 
D1iX6 


Notes 


This data exchange 


was deleted. 
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13 Appendix C - DWG Demonstration 1 End Points 

The content of this appendix was originally a stand-alone document. The information contained 
herein provided some technical details for partners to aid in development. It is mainly included 
for completeness of documentation. 

Table C-1 below describes the endpoints used with Demonstration 1: 


Table C-1: Demonstration 1 Endpoints 


Action Actor Detail ID end point Comments Model 
definitio 
n 

Synchronou Operato Submit ops D1E1 /operation 

s (HTTP r plan with 

POST) volume 

Request 

Synchronou FIMS — Received D1E3 Please detail the HTTP 

s Response HTTP 200 response. ? 

Synchronou Operato Submit ops /operation How far is too far? 

s (HTTP r plan too far in 

POST) advance 

Request 

Synchronou FIMS Bad Request D1E2 /operation 

s Response Received 
HTTP 400 

Synchronou Operato Submit ops /operation 

s (HTTP r LOS plan 

POST) 

Request 

Synchronou FIMS — Received D1E6 /operation flight request was not 

s Response HTTP 200 required 

Synchronou Operato Get /operation 

s (HTTP r operational 

GET) vols 

Synchronou Operato Plan D1E1 /operation 

s (HTTP r modification 

PUT) 

Response FIMS Request D1E3 Please detail the HTTP 
received response. HTTP 200? 
HTTP 200 

Sync Operato Intent to DiE9 /messages 

Request r Cancel 

(HTTP 

POST) 

Response FIMS Received D1E3 Please detail the HTTP 
HTTP 200 response. HTTP 200? 


60 


Action 


Sync 
Request 
(HTTP 
POST) 


Response 


Sync 
Request 


Response 


Sync 
Request 
Response 


ASYNC 
(STOMP 
Queue) 


ASYNC 
(STOMP 
Topic) 
ASYNC 
(STOMP 
Topic) 
ASYNC 
(STOMP 
Topic) 
ASYNC 
(STOMP 
Topic) 


Actor 


Operato 
r 


FIMS 


Operato 
r 


FIMS 


Operato 
r 


FIMS 


FIMS 


FIMS 


FIMS 


FIMS 


FIMS 


Detail 


Intent to Close 


Received 
HTTP 200 
Alert - 
FlyAways, 
Incursion 
Received 
HTTP 200 


Alert - Back to 
conformance 


Received 
HTTP 200 


Notification 
INFORM 


Notification 
ALERT 


Notification 
ALERT 


Position 
subscription 


Operation 
announcemen 
ts 


ID end point 


D1E10 /messages 


D1E11 


D1E3 


D1E15 /messages 


D1E16 


D1E15 /messages 
D1E16 


D1E4, /user/{operator}/decisi 
D1E5, on 

D1E7, 

D1E8 


Model 
definitio 
n 


Comments 


D1E10 when operator 
initiates INTENT to close 
D1E11 when operator 
initiates INTENT to close 
because FIMS 
terminated the plan 


Please detail the HTTP 
response. HTTP 200? 


How are the ACKs for 
Anomalies different from 
regular ACKs (D1E3) 

| don't know that they are 
different. | think they are 
the same. HTTP 200's. 


Please detail the HTTP 
response. HTTP 200? 


Accepted/Denied/Terminat 
ed 

Does Terminated mean 
Land Now? 

Does Operator then 
perform D1E9? 

When a deviation is 
denied, then include 
original plan 


D1E14 /topic/constraintChang Notify AIRSPACE 


e 


D1E12 /topic/emergency 


? /topic/positions 


ALL _ /topic/operations 


constraint change 


Notify other operations of 
UNPLANNED Deviation 


An echo of the position 
reports received by FIMS 


Notify all subscribers of 
approved/accepted 
operations 
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13.1 Private endpoint to trigger async events from FIMS (for managerial use only) 
Table C-2 lists additional private endpoints: 


Table C-2: Private Endpoints 


Action Actor Detail ID end point Comments Model 
definition 
Synchronous Manager Actsasa D1E5, /asyncTriggerForUser FIMS will notify Will include 
(HTTP trigger for D1E7, user the username 
POST) async D1E8 asynchronously and event ID 
messaging to be sent 
from FIMS 
Synchronous Manager Actsasa D1E12, /asyncTriggerForBroadcast FIMS will The event ID 
(HTTP trigger for D1E14 broadcast an to be 
POST) async event (to a broadcasted 
messaging topic) 
from FIMS 
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14 Appendix D - DWG Demonstration 1 FIMS-USS Client Checkout 


The content of this appendix was originally a stand-alone document. The information contained 
herein was the basis for checking the functionality of the various USS systems that were 
developed by the various participants. As the test was dynamic in planning, as was this 
checkout document. This represents the final state of the checkout procedures and is provided 
for completeness and future reference. 


14.1 Introduction 


This document summarizes the steps and requirements for the checkout of a FIMS Client for 
the November Demonstration. They may be used with any client. 


14.1.1 Scope 


These tests are software focused. The idea is to make sure the Client Software has correctly 
implemented all of the features that meet the requirements of the demonstration. The tests will 
make sure the Client is successfully able to do the following: 


Post to all the endpoints (/operations, /messages, /positions) 

Post each of the intent message types required by the DWG Demonstration 1 
Receive all of the synchronous message types 

Receive at least one asynchronous message from each of the stomp queues 
(/user/{operator}/decision, /topic/constraintChange, /topic/emergency) 


Pwn> 


14.2 Testing Artifacts 


For each test, there will be one or more Test Artifacts that will be generated. Each artifact is a 
file. All files with a '.txt' extension will have only ASCII text with the requested results/data. All 
files with a'.json' extension will have only ASCII text representing the JSON (JavaScript Object 
Notation, ref: https://en.wikipedia.org/wiki/JSON) object requested. Other file types may include 
pdf, jpeg, etc. as appropriate for the test. File names for all test artifacts shall follow this pattern: 


FIMS- {providedTag}-{yourOrganizationName}-{artifactName}-{dateOfTest} 
v{versionNumber}. {extension} 


Field definitions are described below in Table D-1: 


Table D-1: Field Definitions 


Field Definition 

providedTag A descriptive string provided by this document. Unique to each phase of 
testing. 

yourOrganizationName A descriptive string unique to your organization's name. Only 


alphanumeric characters (no special chars or spaces allowed). Must be 
the same for all artifacts. 


artifactName Provided by this document. Unique to each test. 
dateOfTest/dateOfCompletion The date the test was performed in the format: yyyYMMDD 


versionNumber An integer, the first submission of the artifact to NASA should be '1' with 
each subsequent submission (as requested by NASA) increasing by 1. 


extension The file type. For example, . txt for general text documents or . json for 
JSON files. 


63 


Instructions regarding submission of the artifacts are provided in the subsections below. 


14.3 Integration Testing 


The operator must complete these tests all in one sitting. They must be done along with a FIMS 
representative. They can be done in person, or via telecommunications. 


14.3.1 Test 0: Integration Sync 


14.3.1.1 Test Purpose 


Ensure proper clock settings to minimize timing issues between the UTM Client machine under 
test and the remote UTM System server. 


14.3.1.2 Test Procedure 


Synchronize the clock on each subsystem within your system. These should include your GCS 
station, the machine your UTM Client runs upon, and potentially your UAS vehicle. 


If possible on each system, run a Network Time Protocol (NTP) client and record the output as 
an artifact (1). The time server that should be targeted is time.nist.gov. Ona Mac or Linux 
machine, the command and output might be something like: 


> sudo ntpdate -u time.nist.gov 


10 Feb 07:56:45 ntpdate[73223]: adjust time server 129.6.15.28 offset 
0.029740 sec 


14.3.1.3 Test Artifacts 


1. FIMS-IntegrationTest- {yourOrganizationName}-SyncClock-{dateOfTest}- 
v{versionNumber}.txt 


14.3.1.4 Test Verification 
Inspect artifact for any anomalies. 


14.3.2. Test 1: Nominal Operation (D1S0T1) 


14.3.2.1 Test Purpose 
To test that a nominal operation can be submitted to FIMS. 


14.3.2.2. Test Procedure 


Submit and record a nominal operation to the FIMS operation endpoint /operations. Record the 
synchronous response message verifying the operation was created. Record the asynchronous 
acceptance message from FIMS at /user/{operator}/decision. 


Data Exchanges: D1E1, D1E3, D1E4 


14.3.2.3. Test Artifacts 
1. FIMS-IntegrationTest- {yourOrganizationName }-NomOpOperation-{dateOfTest } 


v{versionNumber}.json 
2. FIMS-IntegrationTest- {yourOrganizationName } -NomOpSyncResponse- 
{dateOfTest}-v{versionNumber}.json 
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3. FIMS-IntegrationTest-{yourOrganizationName } -NomOpAS yncAcceptance- 


{dateOfTest}-v{versionNumber}.json 


14.3.2.4 Test Verification 
FIMS representative will inspect artifacts for correctness of json content. 


14.3.3 Test 2: Simple Cancel (DISOT2) 


14.3.3.1 Test Purpose 
To test that a cancel intent message can be submitted to FIMS. 


14.3.3.2 Test Procedure 


Submit an operation to the FIMS operation endpoint /operations and receive the asynchronous 
acceptance message from FIMS at /user/{operator}/decision. Submit and record an INTENT 
CANCEL message to the FIMS message endpoint at /messages. 


Data Exchanges: D1E1, D1E3, D1E4, D1E9 


14.3.3.3 Test Artifacts 
1. FIMS-IntegrationTest- {yourOrganizationName}-SimpleCancelIntentCancel- 


{dateOfTest}-v{versionNumber}.json 


14.3.3.4 Test Verification 
FIMS representative will inspect artifacts for correctness of json content. 


14.3.4 Test 3: Denial Received and Acknowledged (DISOT3) 


14.3.4.1 Test Purpose 
To test that a denial can be received from FIMS and acknowledged. 


14.3.4.2. Test Procedure 


Submit an operation to the FIMS operation endpoint /operations and receive the asynchronous 
acceptance message from FIMS at /user/{operator}/decision. Receive and record the 
asynchronous DENIED message from FIMS at /user/{operation}/decision. Submit and record an 
INTENT ACK_NO_OPERATION message to the FIMS message endpoint at /messages 
acknowledging that no flight operation will be conducted. 


Data Exchanges: D1E1, D1E3, D1E4, D1E7, D1E11 


14.3.4.3 Test Artifacts 


1. FIMS-IntegrationTest- {yourOrganizationName }-DenialInformDenied- 


{dateOfTest}-v{versionNumber}.json 
2. FIMS-IntegrationTest-{yourOrganizationName } -DenialIntentAckNoOp- 


{dateOfTest}-v{versionNumber}.json 


14.3.4.4 Test Verification 
FIMS representative will inspect artifacts for correctness of json content. 
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14.3.5 Test 4: Terminated Operation (D1SOT4) 


14.3.5.1 Test Purpose 
To test that an operation can be terminated by FIMS. 


14.3.5.2 Test Procedure 


Submit an operation to the FIMS operation endpoint /operations and receive the asynchronous 
acceptance message from FIMS at /user/{operator}/decision. Receive and record the 
asynchronous TERMINATED message from FIMS at /user/{operation}/decsion. Submit and 
record an INTENT CLOSE message to FIMS at /messages endpoint. 


Data Exchanges: D1E1, D1E3, D1E4, D1E8, D1E10 


14.3.5.3 Test Artifacts 


1. FIMS-IntegrationTest- {yourOrganizationName }-TerminatedInformTerminated- 
{dateOfTest}-v{versionNumber}.json 


2. FIMS-IntegrationTest-{yourOrganizationName}-TerminatedOpIntentClose- 
{dateOfTest}-v{versionNumber}.json 


14.3.5.4 Test Verification 
FIMS representative will inspect artifacts for correctness of json content. 


14.3.6 Test 5: Plan Submitted Too Early (DISOT5) 


14.3.6.1 Test Purpose 
To test that a request can be submitted too early and the correct message is received. 


14.3.6.2. Test Procedure 


Create an operation with begin time that is more than 24 hours after the current time. Submit the 
operation to the FIMS operation endpoint /operations. Receive and record the asynchronous 
INFORM from FIMS at /user/{operator}/decision indicating PLAN_SUBMITTED_TOO_EARLY 


Data Exchanges: D1E1, D1E3, D1E2 


14.3.6.3 Test Artifacts 


1. FIMS-IntegrationTest- {yourOrganizationName}-SubmittedInformEarly- 
{dateOfTest}-v{versionNumber}.json 


14.3.6.4 Test Verification 
FIMS representative will inspect artifacts for correctness of json content. 


14.3.7 Test 6: Fly Away (D1S0T7) 


14.3.7.1 Test Purpose 
To test that a user can report fly away and receive correct messages from FIMS 
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14.3.7.2. Test Procedure 


Submit an operation to the FIMS operation endpoint /operations and receive the asynchronous 
acceptance message from FIMS at /user/{operator}/decision. Send and record an ALERT 
message with FLY_AWAY alert text to FIMS at /messages. Receive and record synchronous 
message from FIMS reporting notification of anomaly received. Receive asynchronous ALERT 
message reporting no fly zone from FIMS at /topic/constraintChange. Receive and record 
asynchronous ALERT message reporting the UNPLANNED_DEVIATION from FIMS at 
/topic/emergency. Receive and record asynchronous ALERT message requesting continuous 
positions from FIMS at /user/{operator}/decision. Submit and record position to FIMS at 
/positions. Send INTENT CLOSE message to FIMS at /messages. Receive and record 
asynchronous ALERT message indicating removal of no-fly zone from FIMS at 
/topic/constraintChange. 


Data Exchanges: D1E1, D1E3, D1E4, D1E15, D1E16, D1E14, D1E12, D1E19, D1E17, D1E10, 
D1E14 


14.3.7.3 Test Artifacts 
1. FIMS-IntegrationTest- {yourOrganizationName}-FlyAwayAlertFlyAway- 
{dateOfTest}-v{versionNumber}.json 
2. FIMS-IntegrationTest- 


yourOrganizationName}-FlyAwaySyncAnomalyReceived- 


{dateOfTest}-v{versionNumber}.json 


3. FIMS-IntegrationTest-{yourOrganizationName}-FlyAwayAsyncAlertNoFly- 


{dateOfTest}-v{versionNumber}.json 


4. FIMS-IntegrationTest-{yourOrganizationName}-FlyAwayAsyncAlertUnplanDev- 


5. FIMS-IntegrationTest-{yourOrganizationName}-FlyAwayAsyncAlertContPos- 


{dateOfTest}-v{versionNumber}.json 


6. FIMS-IntegrationTest- {yourOrganizationName}-FlyAwayOpPosition- 


{dateOfTest}-v{versionNumber}.json 


7. FIMS-IntegrationTest-{yourOrganizationName}-FlyAwayAsyncAlertNoFlyCleared- 


{ 
m 
{ 
m 
{ 
{dateOfTest}-v{versionNumber}.json 
{ 
m 
{ 
m 
{ 
m 


{dateOfTest}-v{versionNumber}.json 


14.3.7.4 Test Verification 
FIMS representative will inspect artifacts for correctness of json content. 


14.3.8 Test 7: Authorization Not Required (DISOTS8) 


14.3.8.1 Test Purpose 
To test that a message can be received that Authorization is not required 


14.3.8.2. Test Procedure 


Create an operation where all operation volumes contain beyond_visual_line_of_sight=false. 
Submit the operation to the FIMS operation endpoint /operations. Record and receive the 
asynchronous Authorization Not Required from FIMS at /user/{operator}/decision. 

Data Exchanges: D1E1, D1E3, D1E6 

1. FIMS-IntegrationTest- {yourOrganizationName } -AuthNotRequiredAsync- 
{dateOfTest}-v{versionNumber}.json 


14.3.8.3 Test Verification 
FIMS representative will inspect artifacts for correctness of json content. 
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14.3.9 Test 8: Positions requested and sent (DISOTY) 


14.3.9.1 Test Purpose 
To test that continuous positions can be requested and sent. 


14.3.9.2. Test Procedure 


Submit an operation to the FIMS operation endpoint /operations and receive the asynchronous 
acceptance message from FIMS at /user/{operator}/decision. Receive asynchronous message 
from FIMS at /user/{operator}/decision requesting continuous position reports. Begin sending 
positions to /positions endpoint. Receive and record asynchronous message from FIMS at 
/user/{operator}/decision cancelling position request, and discontinue sending positions. 


Data Exchanges: D1E1, D1E3, D1E4, D1E19, D1E17, D1E20 


1. FIMS-IntegrationTest- {yourOrganizationName }-ContinuousPositionRequest-— 
{dateOfTest}-v{versionNumber}.json 


14.3.9.3 Test Verification 
FIMS representative will inspect artifacts for correctness of json content. 


14.3.10 Test 9: Single Position requested and sent (DISOT10) 


14.3.10.1 Test Purpose 
To test that a single position can be requested and sent. 


14.3.10.2 Test Procedure 


Submit an operation to the FIMS operation endpoint /operations and receive the asynchronous 
acceptance message from FIMS at /user/{operator}/decision. Receive and record asynchronous 
message from FIMS at /user/{operator}/decision requesting single position reports. Send a 
single position to /positions endpoint. 


Data Exchanges: D1E1, D1E3, D1E4, D1E18, D1E17 


1. FIMS-IntegrationTest- {yourOrganizationName}-SinglePositionRequest- 
{dateOfTest}-v{versionNumber}.json 


14.3.10.3 Test Verification 
FIMS representative will inspect artifacts for correctness of json content. 
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15 Appendix E - DWG Demonstration 1 FIMS-USS Interface 


The content of this appendix is a technical document best viewed with appropriate tools, but is 


human readable on its own. This is the specification to which both the FIMS and the various 


USS implementations adhered to for the demonstration. Note that the data definitions were 
based on the various discussions and documentation referenced elsewhere in this document. 


swagger: "2.0" 


info: 


description: "This API describes the RESTful interface from a UAS Service 
Supplier (USS) to the Flight Information Management System (FIMS) within UTM. 
There is an additional API for asynchronous communications that is described in 


the Subscription Points section." 


version: "v2" 
title: "UTM Research Platform, FIMS-USS Interface" 
contact: 


name: NASA Ames Research Center, Aviation Systems Division 


url: https://utm.arc.nasa.gov/ 
email: joseph.rios@nasa.gov 
license: 
name: NASA Open Source Agreement 
url: https://ti.arc.nasa.gov/opensource/nosa/ 
termsOfService: 

A. No Warranty: THE SUBJECT SOFTWARE IS PROVIDED "AS IS" WITHOUT ANY WARRANTY 
OF ANY KIND, EITHER EXPRESSED, IMPLIED, OR STATUTORY, INCLUDING, BUT NOT LIMITED 
TO, ANY WARRANTY THAT THE SUBJECT SOFTWARE WILL CONFORM TO SPECIFICATIONS, ANY 
IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR 
FREEDOM FROM INFRINGEMENT, ANY WARRANTY THAT THE SUBJECT SOFTWARE WILL BE ERROR 
FREE, OR ANY WARRANTY THAT DOCUMENTATION, IF PROVIDED, WILL CONFORM TO TH 
SUBJECT SOFTWARE. THIS AGREEMENT DOES NOT, IN ANY MANNER, CONSTITUTE AN 
ENDORSEMENT BY GOVERNMENT AGENCY OR ANY PRIOR RECIPIENT OF ANY RESULTS, RESULTING 
DESIGNS, HARDWARE, SOFTWARE PRODUCTS OR ANY OTHER APPLICATIONS RESULTING FROM USE 
OF THE SUBJECT SOFTWARE. FURTHER, GOVERNMENT AGENCY DISCLAIMS ALL WARRANTIES AND 
LTABILITIES REGARDING THIRD-PARTY SOFTWARE, IF PRESENT IN THE ORIGINAL SOFTWARE, 
AND DISTRIBUTES IT "AS IS." 
B. Waiver and Indemnity: RECIPIENT AGREES TO WAIVE ANY AND ALL CLAIMS AGAINST 
THE UNITED STATES GOVERNMENT, ITS CONTRACTORS AND SUBCONTRACTORS, AS WELL AS ANY 
PRIOR RECIPIENT. IF RECIPIENT''S USE OF THE SUBJECT SOFTWARE RESULTS IN ANY 
LIABILITIES, DEMANDS, DAMAGES, EXPENSES OR LOSSES ARISING FROM SUCH USE, 
INCLUDING ANY DAMAGES FROM PRODUCTS BASED ON, OR RESULTING FROM, RECIPIENT''S USE 
OF THE SUBJECT SOFTWARE, RECIPIENT SHALL INDEMNIFY AND HOLD HARMLESS THE UNITED 
STATES GOVERNMENT, ITS CONTRACTORS AND SUBCONTRACTORS, AS WELL AS ANY PRIOR 
RECIPIENT, TO THE EXTENT PERMITTED BY LAW. RECIPIENT''S SOLE REMEDY FOR ANY SUCH 
MATTER SHALL BE THE IMMEDIATE, UNILATERAL TERMINATION OF THIS AGREEMENT. 
host: "tmiserver.arc.nasa.gov" 


basePath: "/fims" 


= 


= 


Fl 


rr 
I 


Fl 


x 
x 


x 
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schemes: 


ta 


re 


en 


re 


pa 


https 
gs: # Have to add 'A' 'B' etc since ordering isn't respected in SwaggerUl. 
name: A. FIMS Endpoints 


description: The primary RESTful endpoints for operators accessing FIMS 
externalDocs: 

url: "https://tmiserver.arc.nasa.gov/fims/api/" 

description: NASA FIMS server generated from this API specification. 


name: B. Subscription Points 
description: Non-REST endpoints for asynchronous communications with FIMS 
name: C. Data Types 
description: Psuedo endpoints used for the documentation of the data schema 
name: D. Version 
description: Get version 
sponses: 
WRONG PROTOCOL: 
description: A RESTful call was made to this endpoint but this is not a REST 


dpoint. Do not use this endpoint for REST calls. 
BadRequest: 
description: "Bad request. Typically validation error. Fix your request and 
ery. 
schema: 
Sref: "#/definitions/FIMSApiResponse" 
AuthenticationError: 
description: "Authentication Error" 
schema: 
Sref: "#/definitions/FIMSApiResponse" 


AuthorizationError: 


description: "Authorization Error" 
schema: 
Sref: "#/definitions/FIMSApiResponse" 
ResourceNotFound: 
description: "Resource not found" 
schema: 
Sref: "#/definitions/FIMSApiResponse" 


ths: 
/operations: 
post: 
tags: 
- A. FIMS Endpoints 
summary: Submit an operation to FIMS 


security: 
- userBasic: [ ] 

operationId: postOperation 
description: Allows for submission of an operation plan to FIMS. 
consumes: 

- application/json 
produces: 

- application/json 


parameters: 
- in: body 
name: operation 
description: Operational plan to add 
required: true 
schema: 
Sref: "#/definitions/Operation" 
responses: 
201: 


description: Operation Plan request rec 
schema: 
Sref: "#/definitions/FIMSApiResponse" 
400: 
description: "Bad request. Typically val 
and retry." 
schema: 
Sref: "#/definitions/FIMSApiResponse" 
403: 
description: "Invalid ID supplied. Fix 
schema: 
Sref: "#/definitions/FIMSApiResponse" 
get: 
tags: 
- FIMS Endpoints 
summary: Return operation(s) from FIMS 
description: Gets the operations from FIMS. 
operationId: getOperations 
produces: 
- application/json 
responses: 
200: 


ived. 


idation error. Fix your request 


authorization and retry." 


schema: 
type: array 
items: 
Sref: "#/definitions/Operation" 
403: 
description: "Unauthorized user." 
schema: 
Sref: "#/definitions/FIMSApiResponse" 
404: 
description: "Operations not found." 
schema: 
Sref: "#/definitions/FIMSApiResponse" 


/operations/{gufi}: 
get: 
tags: 
- FIMS Endpoints 


description: "Operations retrieved succ 


ssfully." 


summary: Return an operation from FIMS 
description: Get a specific operation from FIMS by gufi 
operationId: getOperationByGufi 
produces: 
- application/json 
parameters: 
- in: path 
name: gufi 
description: "GUFI of the operation" 
required: true 
type: string 
format: uuid 
responses: 
200: 
description: "Operation retrieved." 
schema: 
Sref: "#/definitions/Operation" 
403: 
description: "Unauthorized user." 
schema: 
Sref: "#/definitions/FIMSApiResponse" 
404: 
description: "Operations not found." 
schema: 
Sref: "#/definitions/FIMSApiResponse" 
put: 
tags: 
- A. FIMS Endpoints 


summary: Modify an operation 


security: 
- userBasic: [ ] 
description: Allows for modifying of an operation plan in 
operationId: updateOperation 
consumes: 
- application/json 
produces: 
- application/json 
parameters: 
- in: path 
name: gufi 
description: "GUFI of the operation to update" 
required: true 
type: string 
format: uuid 
- in: body 
name: operation 
description: Operation updates 
required: true 


schema: 


FIMS. 


Sref: "#/definitions/Operation" 
responses: 
200: 
description: "Operation updated." 
schema: 
Sref: "#/definitions/FIMSApiResponse" 
400: 
description: "Bad request. Typically validation error. Fix your 
and retry." 
schema: 
Sref: "#/definitions/FIMSApiResponse" 
403: 
description: "Unauthorized user." 
schema: 
Sref: "#/definitions/FIMSApiResponse" 
404: 
description: "Operations not found." 
schema: 
Sref: "#/definitions/FIMSApiResponse" 
/positions: 
post: 
tags: 
- A. FIMS Endpoints 
summary: Submit position report 
security: 


- userBasic: [ ] 


request 


description: Allows for submission of position data related to a particular 


operation. 
operationlId: postPosition 
responses: 
201: 
description: "Position posted successfully." 
schema: 
Sref: "#/definitions/FIMSApiResponse" 
400: 
description: "Invalid message. Please fix and retry." 


schema: 
Sref: "#/definitions/FIMSApiResponse" 
parameters: 
- in: body 
name: position 
description: Position to submit 
required: true 
schema: 
Sref: "#/definitions/Position" 
get: 
tags: 
- FIMS Endpoints 
summary: Return position(s) from FIMS 


Se oSR ORE 


description: Get positions 
operationlId: getPositions 
produces: 

- application/json 
responses: 

200: 


description: "Positions retrieved successfully." 


schema: 
type: array 
items: 
Sref: "#/definitions/Position" 
403: 
description: "Unauthorized user." 
schema: 
Sref: "#/definitions/FIMSApiResponse" 
404: 
description: "Requested positions not found." 
schema: 
Sref: "#/definitions/FIMSApiResponse" 


/messages: 
post: 
tags: 
- A. FIMS Endpoints 
summary: Submit a message to FIMS 
security: 
- userBasic: [ ] 
description: Allows posting of a message to FIMS. Typically an 
message related to a particular operation. 
operationId: postMessage 
consumes: 
- application/json 
produces: 
- application/json 
responses: 
201: 
description: "Message received successfully." 


schema: 
Sref: "#/definitions/FIMSApiResponse" 
400: 
description: "Invalid message. Please fix and retry." 


schema: 
Sref: "#/definitions/FIMSApiResponse" 
403: 
description: "Unauthorized user." 
schema: 
Sref: "#/definitions/FIMSApiResponse" 
parameters: 


- name: message 


intent 


in: body 
description: Message object being sent 


required: true 
schema: 
Sref: "#/definitions/Message" 
cet: 
tags: 
- FIMS Endpoints 
summary: Return message(s) from FIMS 
description: Get all the messages 
operationId: getMessages 
produces: 
- application/json 
responses: 
200: 
description: "Messages retrieved successfully." 


schema: 
type: array 
items: 
Sref: "#/definitions/Message" 
403: 
description: "Unauthorized user." 
schema: 
Sref: "#/definitions/FIMSApiResponse" 
404: 
description: "Messages not found." 
schema: 
Sref: "#/definitions/FIMSApiResponse" 


/user/{operator}/decision: 
get: 
tags: 
- B. Subscription Points 
summary: Subscription point for receiving decisions from FIMS 
description: | 
Each operator has a designated queue for decisions. This queue will 


provide InformMessage data related to the specified operator's operations. For 


example, after an operator POSTs an operation to the /operations RESTful 
endpoint, that operator will receive the appropriate InformMessage (ACCEPTED, 
DENIED, etc.) via this queue. 
See the schema information describing InformMessages included within this 
document to understand the data that will be received via this queue. 
Note that if you are viewing this in a SwaggerUI, the "try it out" 
feature will not work since this is not a RESTful endpoint. 
responses: 
410: 
Sref: "#/responses/WRONG PROTOCOL" 
produces: 
- application/json 


parameters: 

- in: path 
name: operator 
description: "the user id" 
required: true 


type: string 


/topic/positions: 
cet: 
tags: 
- B. Subscription Points 
summary: Subscription point for receiving position reports 
description: | 
Stakeholders should subscribe to this topic to receive position reports 
provided to the FIMS by various operators. This is essentially an echo of the 
Postion data POSTed to the /positions endpoint. 
See the schema information describing Postions included within this 


document to understand the data that will be received via this queue. 


Note that if you are viewing this in a SwaggerUI, the "try it out" 
feature will not work since this is not a RESTful endpoint. 
responses: 
410: 
Sref: "#/responses/WRONG PROTOCOL" 
produces: 
- application/json 
/topic/operations: 
get: 
tags: 
- B. Subscription Points 
summary: Subscription point for receiving announcements about operations 
description: | 
Stakeholders should subscribe to this topic to receive announcements 
about operations that have been accepted/authorized. Information about denied 


operations will not be provided here. 
See the schema information describing Operations included within this 
document to understand the data that will be received via this queue. 
Note that if you are viewing this in a SwaggerUI, the "try it out" 
feature will not work since this is not a RESTful endpoint. 
responses: 
410: 
Sref: "#/responses/WRONG PROTOCOL" 
produces: 
- application/json 
/topic/constraintChange: 
get: 
tags: 
- B. Subscription Points 
summary: Subscription point for airspace constraint changes 


description: | 


Stakeholders should subscribe to this topic to get alert messages 


regarding airspace constraint changes. 

Note that if you are viewing this in a SwaggerUI, 
feature will not work since this is not a RESTful endpoint. 
operationId: topicConstraintChangeUsingGET 

produces: 
- application/json 
responses: 
410: 
Sref: "#/responses/WRONG PROTOCOL" 


/topic/emergency: 
get: 
tags: 
- B. Subscription Points 
summary: Subscription point for emergency alerts 


description: | 


the "try it out" 


Stakeholders should subscribe to this topic to get alert messages 


regarding emergencies. 
Note that if you are viewing this in a SwaggerUI, 
feature will not work since this is not a RESTful endpoint. 
operationId: topicEmergencyUsingGET 
produces: 
- application/json 
responses: 
410: 
Sref: "#/responses/WRONG PROTOCOL" 


/schema/Operation: 
Cetus 
tags: 
- C. Data Types 
summary: Operation schema 
description: | 


Illustrates an operation in JSON. This endpoint is not intended for use. 


the "try it out" 


Note that if you are viewing this in a SwaggerUI, the "try it out" 


feature will not work since this is not a RESTful endpoint. 
produces: 
- application/json 
responses: 
200: 
description: OK 
schema: 
Sref: "#/definitions/Operation" 
410: 
Sref: "#/responses/WRONG PROTOCOL" 
/schema/Point: 


- C. Data Types 
summary: Point schema 
description: | 
Tllustrates an Point in JSON. This endpoint is not intended for use. 
Note that if you are viewing this in a SwaggerUI, the "try it out" 
feature will not work since this is not a RESTful endpoint. 
produces: 
- application/json 
responses: 
200: 
description: OK 
schema: 
Sref: "#/definitions/Point" 
410: 
Sref: "#/responses/WRONG PROTOCOL" 


/schema/LineString: 
Cet: 

tags: 
- C. Data Types 

summary: LineString schema 

description: | 
Illustrates an LineString in JSON. This endpoint is not intended for use. 
Note that if you are viewing this in a SwaggerUI, the "try it out" 


| feature will not work since this is not a RESTful endpoint. | 
produces: 
- application/json 
responses: 
200: 
; description: OK 
schema: 
Sref: "#/definitions/LineString" 
410: 
Sref: "#/responses/WRONG PROTOCOL" 
/schema/Polygon: 
get: 
tags: 
- C. Data Types 
summary: Polygon schema 
description: | 
Illustrates an Polygon in JSON. This endpoint is not intended for use. 
H Note that if you are viewing this in a SwaggerUI, the "try it out" i 
| feature will not work since this is not a RESTful endpoint. 
produces: 
- application/json 
responses: 
200: 
i description: OK 
schema: 


Sref: "#/definitions/Polygon" 
410: 
Sref: "#/responses/WRONG PROTOCOL" 
/schema/InformMessage: 
cet: 
tags: 
- C. Data Types 
summary: Inform Message schema 
description: | 
Tllustrates the FIMS Inform Message. This is FIMS' reply to an Intent. 
This endpoint is not intended for use. 
Note that if you are viewing this in a SwaggerUI, the "try it out" 
feature will not work since this is not a RESTful endpoint. 
operationId: informMsgUsingGET 
produces: 
- application/json 
responses: 
200: 
description: OK 
schema: 
Sref: "#/definitions/InformMessage" 
410: 
Sref: "#/responses/WRONG PROTOCOL" 
/schema/IntentMessag 


tags: 
- C. Data Types 


summary: Intent Message schema 
description: | 
Illustrates the FIMS Intent Message. Your Intent generates a FIMS Inform. 
This endpoint is not intended for use. 
Note that if you are viewing this in a SwaggerUI, the "try it out" 
feature will not work since this is not a RESTful endpoint. 
operationId: intentMsgUsingGET 
produces: 
- application/json 
responses: 
200: 
description: OK 
schema: 
Sref: "#/definitions/IntentMessage" 
410: 
Sref: "#/responses/WRONG PROTOCOL" 
/schema/AlertMessag 
get: 


tags: 
- C. Data Types 


summary: Alert Message schema 


description: | 


get: | 


Illustrates the FIMS Alert Message. FIMS may send out Alert Messages 
time to time. This endpoint is not intended for use. 
Note that if you are viewing this in a SwaggerUI, the "try it out" 
feature will not work since this is not a RESTful endpoint 
operationId: alertMsgUsingGET 
produces: 
- application/json 
responses: 
200: 
description: OK 
schema: 
Sref: "#/definitions/AlertMessage" 
410: 
Sref: "#/responses/WRONG PROTOCOL" 
/schema/ConstraintMessage: 
cet: 
tags: 
- C. Data Types 
summary: Constraint Message schema 


description: | 


Tllustrates the FIMS Constraint Message. FIMS will send out a Constraint 


Message when a new constraint is put in place. This endpoint is not intended for 


use. 
Note that if you are viewing this in a SwaggerUI, the "try it out" 
feature will not work since this is not a RESTful endpoint 
operationId: constraintMsgUsingGET 
produces: 
- application/json 
responses: 
200: 
description: OK 
schema: 
Sref: "#/definitions/ConstraintMessage" 
410: 
Sref: "#/responses/WRONG PROTOCOL" 
/version: 
cet: 
tags: 
- D. Version 
summary: Get version 


produces: 


- text/plain 


securityDefinitions: 
userApikey: 
type: apikey 
in: header 
name: userApikey 
mgrApikey: 


type: apikey 
in: header 
name: mgrApikKey 
userBasic: 
type: basic 
mgrBasic: 
type: basic 
definitions: 
FIMSApiResponse: 
type: "object" 
properties: 
code: 
type: "intege 
format: "int3 
type: 
type: "string 
message: 
type: "string 
example: 
code: 201 
type: CREATED 
message: Operat 
Operation: 
type: object 
required: 
- registration 


- primary contact 


r" 
QM" 


W 


W 


ion Plan request received. 


_name 


- primary contact _phone 


- controller loca 
- operation _volum 
properties: 
gufi: 
description: 


* *Ignore 
* *Always 
Each oper 
string that conforms 
with a new plan, but 
type: string 
format: uuid 
submit time: 
description: 
type: string 
format: date- 
decision time: 
description: 
operation is updated, 
(see Section 4.1)" 


tion 


es 
> 
don initial submission, assigned by server* 
returned from server* 
ation has a GUFI assigned upon submission. It is a JSON 


to the UUID version 4 specification. Should not be submitted 
is required for modification (PUT). 


"Time the operation submission was received by UTM System." 


time 


"A timestamp set by the UTM System any time the state of th 
for example when the flight goes from PROPOSING to ACCEPTED 


type: 
format: 


string 


date-time 


aircraft_comments: 


description: "Informative text about the aircraft. Not used by the UTM 
System. Only for human stakeholders." 
type: string 
flight _comments: 
description: "Informative text about the operation. Not used by the UTM 
System. Only for human stakeholders." 
type: string 
flight geography description: 
description: "Informative text about the operational geography. Not used 
by the UTM System. Only for human stakeholders." 
type: string 
registration: 
description: "The registration ID of the vehicle flying this operation. 
Note the UTM System assumes a single vehicle per operation currently. This 
registration value is provided to operators upon manual registration of their 
vehicle with NASA." 
type: string 
format: uuid 
flight number: 
description: "Optional. Currently unused by the UTM System, may be 


useful to the operator for identification purposes." 


type: s 
user id: 


descrip 


tring 


tion: "This field is populated based on the provided credentials 


in the HTTPS header." 


type: s 


created by: 


descrip 


operation is created on behalf of an operator by, 


tring 


tion: "The user that created the operation. It is possible that an 


say, a manager. Nominally, this 


field will be equal to user id." 


type: string 
primary contact_name: 
description: "These are required fields. They are not currently checked 
for validity, but clients should endeavor to provide useful, appropriate 
information in these fields. Validity will be checked in the futur Thes 


values should 


represent the contact that should be used in case of an issue with 


the operation before, during, or after that operation." 
type: string 
primary contact_phone: 
type: string 
primary contact _email: 
type: string 
extra_contact_info: 
description: "Any additional contact information that may be useful 
(hours of availability, fax number, communication limitations, etc.)." 
type: string 


state: 


description: "The current state of the operation. Not required for 


submission, will be assigned by the UTM System." 


type: string 


controller location: 


# description: 


"The planned position of the UAS Controller during the 


operation. Assumed to be a static location." 
Sref: "#/definitions/Point" 


gcs_location: 
# description: 


"Tf not submitted, the UTM System will assume the GCS is 


co-located with the UAS Controller. Assumed to be a static location." 
Sref: "#/definitions/Point" 


faa_rule: 


description: "Indication whether this operation is under Part 101-E, 
or a Part TBD. Part TBD is a potential future rule that 


107, Part 107 waiver, 


may cover operations such as those under test by UTM." 


type: string 
enum: 

- PART 107 

- PART _107W 
- PART _101E 
- PART TBD 


waiver certificate number: 


description: "If a waiver has been obtained for the Part 107 rules, then 


submissions with faa_rule=PART_107W, this field is required." 


type: string 


operation volumes: 


description: "Editable. The actual geographical information for the 


operation." 
type: array 
items: 


Sref: "#/definitions/OperationVolume" 


example: 


gufi: "00000000-0000-4444-8888-000000000000" 
submit time: "2016-10-04T09:15:40.7272" 
decision time: "2016-10-04T09:15:40.7272" 


aircraft_comments: "Comments about the aircraft" 


flight _comments: 


"Comments about the flight" 


flight geography description: "A description of the geography" 


registration: "00000000-0000-4444-8888-000000000000" 
flight number: "Flight number" 


user id: "fimsUser" 


created _ by: "fimsUser" 


primary contact_name: "Jane Pilot" 


primary contact_phone: "XXX-XXX-XXXXK" 


primary contact_email: "pilotjane@janepilot.com" 


extra_contact_info: "Fax: XXX-XXX-XXXX" 


| the operator would have a waiver certificate number. For any operation 


Part 


state: A 
controller location: 
type: Point 
coordinates: [-122.048589,37.414869] 
gcs_location: 
type: Point 
coordinates: [-122.048589,37.414869] 
operation volumes: 
- ordinal: 1 
near structure: false 
ffective time begin: "2017-10-04T09:15:40.7272" 
ffective time end: "2017-10-04T09:25:40.7272" 
actual _time_ end: "2017-10-04T09:25:40.7272" 
conformance time begin: "2017-10-04T09:14:40.7272" 
conformance time_end: "2017-10-04T09:26:40.7272" 
min altitude wgs84 ft: 0.0 
max altitude _wgs84 ft: 300.0 
conform min altitude _wgs84 ft: 0.0 


conform max altitude_wgs84 ft: 400.0 
flight geography: 
type: Polygon 
coordinates: [ 
[ 
[-122.062176579,37.40968041145], 
[-122.05187056889,37.41786527236], 
[-122 .03732647634, 37.41786440108], 
[-122.062176579,37.40968041145], 


] 
conformance geography: 
type: Polygon 
coordinates: [ 
[ 

[-122 .06382530000002, 37.40906970000 
[-122 .05094253233000,37.41930062770 
[-122 .03276206976000, 37.41929920176 
[-122 .06382530000002, 37.40906970000 


a 
a 
y 


] 
] 
] 
] 


] 


beyond visual line of sight: false 


OperationVolume: 
type: object 
required: 


- ordinal 


- effective time begin 
- effective tim nd 


- min_altitude wgs84 ft 
- max altitude wgs84 ft 
- flight_geography 


- beyond visual line of sight 


properties: 
ordinal: 


description: "This integer represents the ordering of the operation 


volume within the set of operation volumes. Need not be consecutive integers." 


type: integer 
near structure: 
description: "Is this operation volume within 400' of a structure?" 
type: boolean 
default: false 
ffective time begin: 


description: "Earliest time the operation will use the operation volume." 
type: string 

format: date-time 

ffective time end: 

description: "Latest time the operation will done with the operation 


volume." 
type: string 
format: date-time 
actual time end: 
description: "Time that the operational volume was freed for use by other 


operations." 


type: string 
format: date-time 


conformance time begin: 


description: "Assigned by UTM System. Time buffer before the submitted 
begin time." 

type: string 

format: date-time 


conformance time end: 


description: "Assigned by UTM System. Time buffer after the submitted 
end time." 
type: string 
format: date-time 
min altitude _wgs84 ft: 
description: "The minimum altitude for this operation in this operation 


volume. In WGS84 reference system using feet as units." 


type: number 
format: double 
max altitude _wgs84 ft: 


description: "The maximum altitude for this operation in this operation 


volume. In WGS84 reference system using feet as units." 

type: number 

format: double 

conform min altitude _wgs84 ft: 

description: "The minimum altitude assigned and used by the UTM System to 
check vertical conformance of an operation. Based on UTM Client-provided min 
altitude." 

type: number 


format: double 
conform max altitude _wgs84 ft: 
description: "The maximum altitude assigned and used by the UTM System to 
check vertical conformance of an operation. Based on UTM Client-provided max 
altitude." 
type: number 
format: double 
flight geography: 
# description: "A description of the operational area. This should be 
the area within which the operation will remain." 
Sref: "#/definitions/Geometry" 
conformance geography: 
# description: "A UTM-generated geography based on the flight geography. 
See Section 4.4.2 for discussion." 
Sref: "#/definitions/Geometry" 
beyond visual line of sight: 


description: "Describes whether the operation volume is beyond the visual 
line of sight of the operator." 
type: boolean 
Position: 

type: object 

required: 

- altitude_gps wgs84 ft 

- altitude _num_gps_ satellites 

- gufi 

- hdop_ gps 

- location 

- time measured 

- time_sent 


- track ground speed kn 


- track _true_north deg 


- vdop_ gps 


properties: 
air speed source: 
type: string 
description: Required if air speed _ track _kn is submitted. No requirements 


yet on the values here, but suggestions include ESTIMATED or MEASURED. 


air speed _ track kn: 
type: number 
format: double 
description: Air speed in relation to the direction of travel of the 


aircraft. 


Value may be negativ 
altitude _gps wgs84 ft: 
type: number 
format: double 
description: The altitude as measured via a GPS device on the aircraft. 
Units 
in feet using the WGS84 reference system. 


altitude _num_gps_ satellites: 


type: 
format: 


description: 


integer 


int32 
Number of satellites used in calculating the 


altitude gps wgs84 ft. 


enroute positions id: 


type: s 
format: 
descrip 
gufi: 
type: s 
format: 
descrip 
Required upon 


POSTing a new position. 


version 


tring 
uuid 
tion: Each position will be assigned a UUIDv4 by the FIMS 
tring 


uuid 


tion: Each operation has an GUFI assigned upon submission. 


It is a JSON string, but conforms to the UUID 


4 specification 


hdop_gps: 


type: 
format: 


description: 


onboard 
GPS. 
location: 


# description: 


fragment." 
"Sref": 


number 


double 
The horizontal dilution of precision as provided by the 


"A description of the 2D location. A Point geojson 


"#/definitions/Point" 


time measured: 


type: s 
format: 
descrip 
with 
the G 


tring 
date-time 


tion: tim 


The time the position was measured. Likely th provided 


PS position reading. 


time received: 


type: s 
format: 
descrip 


time 


tring 


date-time 


tion: Not required for submission, assigned by the UTM System. The 


the position was received by the UTM System. 


time sent 


type: 
format: 


description: 


string 


date-time 
The time the position was sent. 


track ground speed kn: 


type: 
format: 


description: 


number 


double 


Ground speed int the direction of travel. Value must be >= 


In knots. 


track magnetic north deg: 
type: number 
format: double 
description: The direction of travel relative to magnetic north in 
degrees. 
Value must be >= 0.0 and < 360.0. 
track true north deg: 
type: number 
format: double 
description: The direction of travel relative to true north in degrees. 
Value 
must be >= 0.0 and < 360.0. 
user id: 
type: string 
description: Not required for submission. This field is populated based 
on the 
provided credentials in the HTTPS header. 
vdop_gps: 
type: number 
format: double 
description: The vertical dilultion of precision as provided by the 
onboard 
GPS. 
example: 
altitude gps wgs84 ft: 1111.111 
altitude num _gps_ satellites: 22 
air speed source: "MEASURED" 
gufi: "00000000-0000-4444-8888-000000000000" 
hdop_gps: 77.7 
time measured: "2016-10-04T09:15:40.7272" 
time sent: "2016-10-04T09:15:40.7272" 
time received: "2016-10-04T09:15:42.7272" 
track ground speed kn: 33.33 
track true north deg: 235.027287562664 
track magnetic north deg: 237.123456789123 
vdop_gps: 88.8 


location: 
type: "Point" 
coordinates: 
- -122.05635935068132 
- 37.41436490284069 
Geometry: 
required: 
- type 
type: object 
discriminator: type 
description: "A geometry object in two dimensional space." 
properties: 
type: 


type: string 


Point: 

required: 

- coordinates 
allOf: 
- Sref: "#/definitions/Geometry" 
- type: object 

properties: 

coordinates: 


type: array 


description: Pair of longitude-latitude values. 


provided for altitude, it is silently ignored. 
items: 
type: number 
format: double 
example: 
type: Point 
# Moffet Federal Airfield 


If a third element is 


# http://bl.ocks.org/d/3410a0£498572d74972719c39382ceff 


coordinates: [-122.048589,37.414869] 
LineString: 
required: 
- coordinates 
allOf: 
- Sref: "#/definitions/Geometry" 
- type: object 
properties: 
coordinates: 
type: array 
items: 
type: array 
items: 
type: number 
format: double 
example: 
type: LineString 


coordinates: [ 


lst point NASA Ames Research Center 
2nd point 1lmi bearing 45° 


3rd point lmi bearing 90° 

-122.06382530000002,37.4090697], 
-122.05094253233,37.4193006277], 
-122.03276206976,37.41929920176] 


] 
Polygon: 
required: 
- coordinates 
allOf: 


http://bl.ocks.org/d/655a22e1d3c1a85f£4304a2133409d76d 


- Sref: "#/definitions/Geometry" 


- type: object 
properties: 
coordinates: 
type: array 
items: 
type: array 
items: 
type: array 
items: 
type: number 
format: double 
example: 
type: Polygon 
coordinates: [ 
http://bl.ocks.org/d/7e0bffe48 f£38444b2 9bbb2e7ec10032 
outer ring 


this is a triangle starting at NASA Ames Research Center 


2nd point imi bearing 45° 
3rd point 1lmi bearing 90° 
4th point is same as lst to close the polygon 


-122.06382530000002,37.40906970000], 
-122.05094253233000,37.41930062770], 
-122.03276206976000,37.41929920176], 
-122.06382530000002,37.40906970000 


, 


inner ring 


lst point is .lmi bearing 65° from lst of outer ring 
2nd point .8mi bearing 45° 

3rd point .8mi bearing 90° 

4th point is same as lst to close the polygon 


[-122.062176579,37.40968041145], 
[-122.05187056889, 37.41786527236], 
[-122.03732647634,37.41786440108], 
[-122.062176579,37.40968041145], 


] 
Message: 
type: object 
discriminator: category 
required: 
- gufi 
- category 
properties: 
message _ id: 
description: A UUID assigned to this message by the FIMS 
type: string 


format: 
origin: 

type: s 

enum: 

- FIMS 


- MANAG 
descrip 
user: 


descrip 


uuid 


tring 


ER 
The user or process that generated this message 


tion: "Populated by the UTM System. The target user for a message 


from the UTM System." 


type: s 
gufi: 

descrip 

message." 

type: s 

format: 
category: 

type: s 


enum: 


tring 


tion: "The assigned GUFI for the operation referenced by the 


tring 


uuid 


tring 


- AlertMessage 


- Inten 


tMessage 


- InformMessage 


- Const 
free text 
descrip 
type: ¢ 


sent time: 


descrip 

the time it was 
type: s 

format: 

ack time: 
descrip 


message receiv 


type: s 

format: 
example: 
"00 
category: 


gufi: 

origin: " 

free text 

sent_time 

intent_me 

AlertMessage: 
required: 

- alert_mes 

- alert_sev 

- alert _tex 


raintMessage 
tion: Any remarks or messaging that does not fit any other fields 


tring 


"Hither th th 
received by the UTM System." 


tion: tim message was sent by the UTM System or 
tring 

date-time 

tion: A timestamp stored in the DB upon acknowledgment from the 


A 


tring 


date-time 


000000-0000-4444-8888-000000000000" 
"IntentMessage" 

CLIENT" 

: "An intent message from a client 
: "2016-10-04T09:15:42.7272" 

"CLOSE" 


(for example)" 


ssage: 


sage 


erity 
t 


- Sref: "#/definitions/Message" 
- type: object 
properties: 
alert message: 
type: string 
enum: 
- WEATHER 
- SECURITY 
- OPERATIONS 
- SYSTEM 
- GENERAL 


alert severity: 
type: string 
enum: 
- INFORMATIONAL 
- NOTICE 
- WARNING 
- CRITICAL 
— EMERGENCY 
alert text: 
type: string 
i enum: ' 
- UNPLANNED LANDING 
- UNCONTROLLED LANDING 
- FLY AWAY 
- HIJACK 
- CONSTRAINT CHANGE 
- UNPLANNED DEVIATION 
- ROGUE 
- OTHER SEE FREE TEXT 
- POSITION REPORT REQUEST SINGLE 

- POSITION REPORT REQUEST CONTINUOUS 
- POSITION REPORT REQUEST CANCEL 
- OFF COURSE 
- BACK TO CONFORMANCE 


warnings: 


type: array 
items: 
Sref: "#/definitions/Warning" 
example: 

gufi: "00000000-0000-4444-8888-000000000000" 
category: "AlertMessage" 
origin: "FIMS" 
sent_time: "2016-10-04T09:15:42.7272" 
alert message: "OPERATIONS" 
alert _severity: "WARNING" 
alert text: "ROGUE" 
free text: " 


reason=RogueNearby, 
reasonDetail=nearby operation 86250f05-d89c-40cf-b932-aa8d10a426a2 in 


state U is lateral distance 711.45 feet and vertical danger zon nvelope 600 
feet; 

This alert message valid for the next 30 seconds (far lateral/far 
altitude), 

vehicleType=FixedWing 

vehicleModelName=Silent Falcon, 

longLat=-119.87933795058 39.69702548394, 

alt_gps_wgs84 f£t=5187.3645438621, 

track ground speed kn=0.77703200548507, 


track magnetic north deg=null" 
IntentMessage: 
required: 
- intent message 
allot: 
- $ref: "#/definitions/Message" 
- type: object 
properties: 
intent_message: 
type: string 
enum: 
- ACK NO OPERATION 
CANCEL 


- CLOSE 


example: 
gufi: "00000000-0000-4444-8888-000000000000" 
category: "IntentMessage" 
origin: "CLIENT" 
sent time: "2016-10-04T09:15:42.727Z" 
intent _message: "CANCEL" 
InformMessage: 
alloOf: 
- Sref: "#/definitions/Message" 
- type: object 
properties: 
inform_message: 
type: string 
enum: 
- PLAN SUBMITTED TOO EARLY 


ACCEPTED 
- AUTH 
- DENI 
N 
A 
T 


ERM 


violations: 


description: "Included with messages from the INFORM category with 


inform_message = DENIED." 


type: array 
items: 
Sref: "#/definitions/Violation" 
warnings: 
type: array 
items: 
Sref: "#/definitions/Warning" 
example: 
gufi: "00000000-0000-4444-8888-000000000000" 
category: "InformMessage" 
origin: "FIMS" 
free text: "Plan DENIED. See violations field of this message for 
constraining violation(s) and the violating volume(s)." 
sent_time: "2016-10-04T09:15:42.7272" 


inform _message: "DENIED" 


violations: '[ 


{"type":"Operations","violating volume":1,"constraining volume":1,"constraining i 
d":"90710543-6b18-44c9-ala6-a3ecd60d14"} 
}! 
ConstraintMessage: 
allOf: 
- Sref: "#/definitions/Message" 
- type: object 


constraint_geography: 
# description: "A description of the geography of the constraint." 
Sref: "#/definitions/Geometry" 

begin time: 
description: "The time that the constraint begins. Null or no value 


implies infinity begin time." 


type: string 
format: date-time 
end_time: 
description: "The time that the constraint ends. Null or no value 
implies infinity end time." 
type: string 
format: date-time 
example: 
gutie "AN 
category: "ConstraintMessage" 
origin: "FIMS" 
free text: "Constraint added." 
sent_time: "2016-11-29T01:16:41.7272" 
constraint geography: 
type: Polygon 
coordinates: [ 
[ 
[-122.062176579, 37.40968041145], 


properties: 


[-122.05187056889,37.41786527236], 
[-122.03732647634,37.41786440108], 
[-122.062176579,37.40968041145], 


] 
begin time: "2016-11-29T01:16:41.7272" 
end_ time: "2016-11-30T01:16:41.7272" 
Violation: 
type: object 
properties: 
type: 
type: string 
constraining id: 
type: string 
format: uuid 
constraining volume: 
type: integer 
violating volume: 
type: integer 
Warning: 
type: object 
properties: 
warning id: 
type: string 
#externalDocs: 
# description: > 
# ### Find out more about Swagger_ 
# url: "http://swagger.io" 
x-azure-api-id: "sh-1469571953760" 


95 


